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ABSTRACT 

This  report  documents  the  development  of  a  computational  model  to  simulate  the  complex 
flow  induced  by  helicopter  rotors,  using  an  open-source  computational  fluid  dynamics  (CFD) 
code,  OpenFOAM™.  This  computational  code  is  now  being  used  to  perform  large-scale  multi¬ 
physics  simulations  of  the  flow  field  around  helicopters  including  exhaust  plumes  and  their 
airframe  impingement.  The  rotor  downwash  model  was  validated  against  available 
experimental  data  on  rotor-fuselage  interactions  published  by  the  Georgia  Institute  of 
Technology.  The  OpenFOAM  predicted  result  was  also  shown  to  compare  favourably  with 
ANSYS  Fluent  predictions. 
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Development  of  Virtual  Blade  Model  for  Modelling 
Helicopter  Rotor  Downwash  in  OpenFOAM 


Executive  Summary 


The  Infrared  Signatures  and  Aerothermodynamics  (IRSA)  group  within  DSTO  is 
tasked  with  providing  measurement-validated  infrared  signature  models  of  air 
vehicles  to  the  Australian  Defence  Force  (ADF). 

In  general,  both  fixed  and  rotary-wing  aircraft  will  exhibit  a  significant  area  of 
unobscured  hot  exhaust  surface.  For  such  aircraft,  the  infrared  signature  is  dominated 
by  direct  emissions  from  these  unobscured  hot  surfaces,  while  the  signature 
contribution  from  surface  reflections  and  plume  emissions  can  largely  be  neglected 
without  great  loss  of  accuracy.  However,  for  low-observable  aircraft,  like  helicopters 
fitted  with  infrared  suppressors,  a  lack  of  observable  exhaust  surfaces  means  that  this 
simplification  does  not  apply.  Infrared-suppressed  helicopters  are  becoming 
increasingly  important  to  the  ADF  and  an  understanding  of  their  infrared  signature 
requires  a  much  more  comprehensive  understanding  of  their  associated  air  and 
exhaust  flows. 

Infrared  suppression  systems  principally  function  by  denying  direct  line-of-sight  to  hot 
engine  exhaust  surfaces  at  tactically  critical  viewing  aspects.  Consequently,  aircraft 
fitted  with  infrared  suppression  systems  have  signatures  which  are  dominated  by 
exhaust  plume  emissions,  emissions  from  airframe  surfaces  incidentally  heated  by 
exhaust  impingement  and  indirect  reflections  of  directly  obscured  hot  surfaces  on  rotor 
blades,  wings,  cavities,  etc.  In  the  case  of  a  suppressed  helicopter,  the  ability  to  model 
the  complex  interaction  between  the  hot  engine  exhaust  plume  and  the  rotor 
downwash  is  essential  to  the  prediction  of  its  infrared  signature.  Downwash-plume- 
crosswind  interaction  determines  the  magnitude  and  disposition  of  volumetric  exhaust 
gas  emission  and  localised  surface  emission  due  to  plume  impingement. 

This  report  documents  the  development  of  a  computational  model  to  simulate  the 
complex  flow  induced  by  helicopter  rotors,  using  an  open-source  computational  fluid 
dynamics  (CFD)  code,  OpenFOAM™.  This  computational  code  is  now  being  used  to 
perform  large-scale  multi-physics  simulations  of  the  flow  field  around  helicopters 
including  exhaust  plumes  and  their  airframe  impingement.  These  simulations  exploit 
the  benefit  of  combining  free  open-source  software  with  historically  inexpensive 
computer  cluster  hardware  performance  to  accurately  model  the  signatures  of  low- 
observable  aircraft. 
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Notation 


CO  rotor  blade  angular  velocity  (rad/  s) 

{r,y/,z)  stationary  cylindrical  coordinate  system  local  to  the  rotor  plane 

for  zero  RSP  pitch-bank  angles 


{x,y,z)  global  Cartesian  coordinate  system 

“*■  radial  position  vector  along  the  blade  span 

r 

V  rotor  azimuth  angle 


¥  LRF 


^LRF 


^RSP 


unit  radial  vector  in  the  LRF  rotating  cylindrical  frame  of 
reference 

unit  vector  tangential  to  the  instantaneous  blade  path  in  the  LRF 
rotating  cylindrical  frame  of  reference 

unit  vector  normal  to  the  instantaneous  blade  path  in  the  LRF 
rotating  cylindrical  frame  of  reference 

unit  radial  vector  in  the  RSP  rotating  cylindrical  frame  of 
reference 


¥  RSP 


^RSP 

<J 

N, 

J 

R 

r/ 

^  collective 

(dcos^  -i-5sin^) 

P 

Po 

(Ac  +  sin^^) 


unit  vector  tangential  to  the  line  of  constant  radius  in  the  RSP 
rotating  cylindrical  frame  of  reference 

unit  vector  normal  to  the  RSP  rotating  cylindrical  frame  of 
reference 

rotor  disk  solidity  ratio 

number  of  blade  on  the  rotor 

rotor  advance  ratio 

rotor  disk  radius  (m) 

blade  geometric  angle-of -attack  (deg) 

blade  collective  angle-of -attack  (deg) 

blade  longitudinal  and  lateral  cyclic  pitch  angles  (deg) 

total  blade  flapping  angle  (deg) 

blade  coning  angle  (deg) 

first  harmonic  components  of  the  blade  longitudinal  and  lateral 
flapping  angles  (deg) 


a. 


induced  angle-of-attack  (deg) 
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blade  effective  angle-of-attack  (deg) 

‘LRF 

induced  angle-of-attack  in  the  rotor  LRF  rotating  cylindrical 
frame  of  reference  (deg) 

^LRF 

blade  effective  angle-of-attack  in  the  rotor  LRF  rotating 
cylindrical  frame  of  reference  (deg) 

<P 

blade  twist  angle  (deg) 

velocity  components  (m/  s)  in  the  stationary  global  Cartesian 
frame  of  reference 

(v„  ,  ,  v_  ) 

V  ^RSP  PRSP  ^RSP  / 

velocity  components  (m/  s)  in  the  RSP  stationary  Cartesian  frame 
of  reference 

^LRF  ’  '^¥lRF  ’  ^LRF  ) 

velocity  components  (m/  s)  in  the  LRF  rotating  cylindrical  frame 
of  reference  following  the  blade  path 

v' 

V  LRF 

total  relative  fluid  velocity  component  with  respect  to  the  blade 
tangential  velocity  (m/  s)  in  the  direction  parallel  to  the  blade 
motion  in  the  LRF  rotating  cylindrical  frame  of  reference 

f, 

sectional  blade  force  (N)  in  the  direction  perpendicular  to  the 
blade  chord,  obtained  using  the  2D  Lifting  Line  theory 

L 

sectional  blade  force  (N)  in  the  direction  parallel  to  the  blade 
chord,  obtained  using  the  2D  Lifting  Line  theory 

L 

•'  ^LRF 

sectional  blade  force  (N)  in  the  direction  normal  to  the  blade  path 
in  the  LRF  rotating  cylindrical  frame  of  reference 

f 

¥lrf 

sectional  blade  force  (N)  in  the  direction  tangential  to  the  blade 
path  in  the  LRF  rotating  cylindrical  frame  of  reference 

LRF  ’  ^^LRF 

time-averaged  blade  force  components  (N)  in  the  LRF  rotating 
cylindrical  frame  of  reference 

’  ^¥rSP  ’  ^^RSP 

time-averaged  blade  force  components  (N)  in  the  RSP  rotating 
cylindrical  frame  of  reference 

^^^RSP  ’  ^ypSP  ’  ^^RSP 

time-averaged  blade  force  components  (N)  in  the  RSP  stationary 
Cartesian  frame  of  reference 

[F.^Fy^F.) 

time-averaged  blade  force  components  (N)  in  the  stationary 
global  Cartesian  frame  of  reference 

Q 

blade  2D  lift  coefficient 

Q 

blade  2D  drag  coefficient 

^  local 

magnitude  of  local  velocity  vector  relative  to  each  blade  element, 
neglecting  the  velocity  component  in  the  radial  direction  (m/  s) 
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T 

Q 


c 


Mx 


C 


Mv 


^  turb 

t 

P 

P 

Pt 

P 


u 

C, 


total  rotor  thrust  (N)  in  the  global  Cartesian  frame  of  reference 

total  rotor  torque  (N)  in  the  global  Cartesian  frame  of  reference 

volumetric  momentum  source  in  vector  form  in  the  global 
Cartesian  frame  of  reference  (force  per  unit  computational  cell 
volume) 

rotor  disk  coefficient  of  thrust 
rotor  disk  coefficient  of  pitching  moment 
rotor  disk  coefficient  of  rolling  moment 
turbulent  kinetic  energy  {m^js^^ 

turbulent  dissipation  rate  {m^js^^ 

turbulent  intensity  (%) 
flow  time  (5) 

fluid  density  {kg/m^) 
fluid  molecular  viscosity  {kg  jm-s) 
turbulent  viscosity  {kglms) 
pressure  {pa) 
velocity  vector  {m/s) 
freestream  velocity 

a  reference  static  pressure  based  on  the  freestream  condition 
a  coefficient  in  the  k  -s  turbulence  models 

equivalent  hydraulic  diameter  used  for  evaluating  the  turbulence 
length  scale  in  a  wall  bounded  charmel 
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1.  Introduction 


The  Infrared  Signatures  and  Aerothermodynamics  (IRSA)  group  within  DSTO  is  tasked 
with  providing  measurement-validated  infrared  (IR)  signature  models  of  air  vehicles  to 
the  Australian  Defence  Force  (ADF). 

An  important  element  of  the  IR  signature  modelling  is  the  ability  to  model  the  transport  of 
the  hot  exhaust  plume  around  a  helicopter  under  the  influence  of  the  rotor  downwash. 
The  transport  of  the  hot  exhaust  plume  around  the  helicopter  fuselage  may  have  an 
important  fuselage  heating  effect  due  to  the  impingement  of  the  hot  plume  on  the 
fuselage.  This  needs  to  be  modelled  correctly  to  produce  an  accurate  temperature 
distribution  on  the  engine  nacelles,  fuselage,  rotor  blades,  and  tail  boom.  An  accurate 
temperature  distribution  on  the  fuselage,  nacelles  and  exhaust  plume  is  a  critical  input  for 
generating  an  accurate  IR  signature  prediction  for  the  entire  platform. 

The  transport  of  the  hot  exhaust  plume  around  a  helicopter  is  dependant  on  several 
different  factors,  such  as:  the  freestream  flow;  the  turbulent  air-wake  due  to  the  interaction 
between  the  freestream  flow  and  the  fuselage;  as  well  as  the  rotor  downwash  flow.  It  is 
therefore  critical  that  the  Computational  Fluid  Dynamics  (CFD)  modelling  tools  used  for 
predicting  both  the  flow  and  temperature  fields  are  able  to  accurately  model  the 
interaction  between  each  of  the  different  flow  features  before  the  heat  transfer  rates  and 
the  temperature  distribution  on  the  fuselage  can  be  accurately  predicted. 

ANSYS  Fluent  CFD  software  has  been  used  within  the  group  for  simulating  the  flow 
around  a  helicopter.  The  flow  through  the  rotor  plane  is  modelled  in  ANSYS  Fluent  using 
an  additional  add-on  code  called  "Virtual  Blade  Element  Model"  (VBM)  which  is  available 
by  request  from  ANSYS  distributor!.  Furthermore,  at  Reference  1  DSTO  developed  in- 
house  a  separate  VBM  code,  as  an  add-on  to  ANSYS  Fluent  based  on  Reference  2. 

Since  early  2010,  IRSA  has  been  evaluating  another  CFD  code,  OpenFOAM™,  which  is  an 
open  source  code  and  is  made  available  to  the  public  for  free  (Reference  3),  to  complement 
the  use  of  ANSYS  Fluent.  Unlike  ANSYS  Fluent,  OpenFOAM  avoids  licensing  costs  and 
thus  offers  the  potential  to  run  high  fidelity  simulations  using  a  large  High  Performance 
Computing  (HPC)  cluster  at  a  significantly  lower  cost  than  that  required  by  ANSYS. 
However,  several  gaps  in  the  OpenFOAM^  capabilities  for  performing  the  CFD 
simulation,  as  typically  required  for  simulating  the  flow  around  the  helicopter,  have  been 
identified.  Most  notable  is  the  lack  of  a  VBM  to  model  the  flow  induced  by  a  helicopter 
rotor.  Consequently,  a  task  was  raised  to  develop  the  VBM  capability  using  the 
OpenFOAM  code.  This  development  task  was  jointly  carried  out  with  OpenCFD  Ltd.^  in 
the  United  Kingdom,  which  is  the  original  producer  of  the  OpenFOAM  code.  It  should  be 
noted  that  a  significant  portion  of  the  model  development  is  based  on  the  work  presented 


!  LEAP,  Pty.  Ltd.  is  the  sole  distributor  for  ANSYS  Fluent  in  Australia. 
2  OpenFOAM  Version  1.7.x 

!  OpenCFD,  Ltd.  is  now  wholly  owned  by  ESI,  Ltd.. 


UNCLASSIFIED 


1 


UNCLASSIFIED 

DSTO-TR-2931 

at  References  1,  2  and  4.  This  report  provides  a  detailed  mathematical  description  of  the 
VBM,  its  implementation  in  the  OpenFOAM^^  environment,  and  the  model  validation 
against  available  experimental  data. 

This  report  is  divided  into  six  sections.  A  thorough  description  of  the  mathematical  model 
employed  in  the  VBM  is  presented  at  Section  2.  The  model  implementation  using  the  C++ 
programming  language  and  the  OpenFOAM  library,  including  an  overview  of  the  code 
structure  is  discussed  in  Section  3.  Section  4  describes  the  procedure  for  setting  up  a 
simulation  case  with  the  VBM  in  OpenFOAM.  Sections  5  reports  on  the  code  validation 
and  verification  results  using  available  experimental  data.  Finally,  the  conclusions  and 
recommendations  arising  from  this  development  task  are  discussed  in  Section  6. 

Following  this  development  effort,  a  CFD  simulation  of  the  flow  around  the  MRH-90  in 
hover  and  its  effect  on  fuselage  heating  was  carried  out.  This  work  is  presented  at 
Reference  5,  and  was  considered  to  be  a  suitable  test  case  for  evaluating  the  OpenFOAM 
accuracy  in  performing  the  complex-geometry  complex-flow  CFD  simulations  typically 
required  by  IRSA. 
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2.  Physical  Model  and  Assumptions 

2.1  Overview  of  Rotor  Blade  Modelling  Techniques  in  CFD 

The  airflow  induced  by  the  moving  blades  in  a  helicopter  rotor  is  generally  unsteady  and 
consists  of  complex  flow  features.  As  the  blade  moves  through  the  air,  tip  vortices  are 
generated  on  the  blade  tip,  which  will  interact  with  the  air  induced  through  the  rotor 
plane  along  the  rotor  axis.  This  interaction  typically  produces  a  very  complex 
three-dimensional  unsteady  swirling  air-wake  with  cascading  tip  vortices  at  the  boundary 
of  the  rotor  downwash.  The  downwash  flow  pattern  may  also  vary  depending  on  the  ratio 
of  the  rotor  blade  linear  speed  and  the  helicopter  forward  speed  (known  as  the  "advance 
ratio"). 

Several  techniques  exist  for  modelling  the  flow  through  a  helicopter  rotor  using  CFD. 
These  techniques  vary  in  terms  of  the  model  complexity  and  the  associated  computational 
cost.  The  selected  model  must  consider  the  objective  of  the  simulation  ranging  from 
determining  detailed  blade  characteristics  (e.g.  blade  stall  behaviour  or  accurate  prediction 
of  rotor  lift  and  drag),  to  cases  where  only  the  time-averaged  cumulative  effects  of  the 
rotating  blades  on  the  rotor  air-wake  and  its  interaction  with  the  fuselage  is  considered 
important.  The  latter  scenario  is  deemed  to  be  appropriate  for  predicting  the  transport  of 
the  hot  exhaust  plume  and  its  impingement  on  the  fuselage  skin  for  the  purpose  of  IR- 
signature  prediction. 

The  most  common  technique  used  in  CFD  for  computing  the  time-averaged  flow-field  is 
the  Reynolds-Averaged  Navier-Stokes  (RANS)  simulation.  In  the  RANS  simulation,  the 
fluctuating  velocity  field  is  removed  from  the  system  of  equations.  Turbulence  is  modelled 
by  introducing  a  modelling  quantity  called  "turbulence  viscosity"  to  model  the  increase  in 
the  stress  in  the  flow  due  to  turbulence. 

When  using  the  RANS  simulation  the  time-averaged  effect  of  the  rotor  blade  moving 
through  the  air  can  be  modelled  as  time-averaged  momentum  sources  introduced  in  the 
cell  region  swept  by  the  rotor  blades.  This  region  is  modelled  as  a  disk  with  a  finite 
thickness  made  up  of  a  collection  of  computational  cells.  The  rotor  disk  orientation 
corresponds  to  the  orientation  of  the  Rotor  Shaft  Plane  (RSP),  and  the  disk  radius 
corresponds  to  the  actual  blade  radius. 

In  this  simplified  rotor  model,  there  is  no  need  to  physically  model  the  individual  rotor 
blades  in  the  domain.  Consequently,  the  mesh  does  not  need  to  be  regenerated  or 
"moved"  as  the  blade  moves  through  the  air.  Therefore,  the  resulting  computational  mesh 
has  a  substantially  lower  cell  count  when  compared  to  modelling  the  entire  blade 
geometry,  which  also  significantly  reduces  the  mesh  generation  time. 

Two  variants  of  the  simplified  rotor  model  exist.  The  pressure  disk  rotor  model 
approximates  a  helicopter  rotor  or  propeller  in  a  time  averaged  marmer  using  inflow  and 
outflow  boundary  conditions  at  the  disk's  circular  surfaces  (which  are  the  top  and  bottom 
surfaces  of  the  cylinder).  This  yields  a  pressure  jump  across  the  disk  varying  with  radius 
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and  azimuth.  Such  model  is  known  as  the  "Fan"  boundary  condition.  Alternatively,  Zori 
et  al  (Reference  4)  developed  a  more  accurate  technique  that  replaces  the  rotor  system  with 
momentum  sources  placed  in  the  rotor  disk  region,  yielding  indirectly  a  pressure  jump 
across  the  disk  which  varies  with  the  disk  radial  and  azimuthal  coordinates.  Using  this 
technique,  the  momentum  sources  are  calculated  using  the  well-known  Blade  Element 
Theory  (BET)  which  approximates  the  blade  forces  at  each  point  in  the  rotor  disk  region  by 
using  an  airfoil  lookup  table  that  provides  the  two-dimensional  (2D)  lift  and  drag 
coefficients  for  the  blade  airfoil  considered.  The  latter  rotor  modelling  technique  is  known 
as  VBM,  which  is  the  model  adopted  for  the  current  development  task. 

The  VBM  model  only  allows  for  accurate  aerodynamic  predictions  when  no  flow 
separation  occurs  on  the  actual  blade  for  a  particular  helicopter  control  input  and  flight 
condition.  This  limitation  is  largely  imposed  by  the  use  of  2D  lifting  line  and  drag  line 
curves  for  calculating  the  blade  forces  in  the  rotor  disk  region.  Furthermore,  for  modelling 
helicopter  rotor  in  flight,  the  VBM  requires  the  user  to  know  a  priori  the  correct  orientation 
of  the  rotor  TPP  for  a  particular  blade  collective  and  cyclic  pitch  trim,  and  flight  condition. 
The  orientation  of  the  RSP  must  correspond  to  the  orientation  of  the  rotor  disk  in  the  CFD 
mesh.  Note  that  the  rotor  disk  pitch  and  bank  angles  are  calculated  from  the  mesh,  while 
the  TPP  is  constructed  during  runtime  using  the  blade  flap  angle  as  the  blades  rotate. 
Therefore,  the  origin  and  angle  of  the  TPP  are  different  from  the  origin  and  angle  of  the 
RSP  as  defined  by  the  mesh.  This  will  be  discussed  further  in  Section  2.3. 

The  rotor  blade  flap  angle  profile  for  a  particular  helicopter  type  and  flight  condition  can 
typically  be  obtained  using  various  flight  dynamics  modelling  software,  such  as  FlightLab 
(Reference  6).  The  Rotary  Wing  Operation  (RWO)  group  within  the  Air  Operation  Division 
(AOD)  maintains  a  collection  of  validated  FlightLab  models  for  a  range  of  ADO  helicopter 
types. 

2.2  Overview  of  Rotor  Aerodynamics 

A  brief  overview  of  the  rotor  aerodynamics  will  be  discussed  in  this  section  prior  to  the 
description  of  the  VBM.  This  overview  will  lay  the  necessary  foundation  including  the 
conventions  used  in  the  implementation  of  the  BET  in  a  RANS  algorithm. 

2.2.1  Brief  Description  of  a  Helicopter  Rotor 

A  schematic  of  the  blade  in  the  rotor  plane  system  is  shown  in  Figure  2.1.  It  is  conventional 
to  assume  that  the  rotor  rotation  direction  is  counter-clockwise  (viewed  from  above).  Thus, 
this  direction  of  rotation  in  the  model  is  assumed  to  have  a  positive  angular  velocity,  co. 

In  forward  flight,  and  assuming  a  positive  angular  velocity,  the  right  side  of  the  rotor  disk 
is  termed  the  advancing  side,  while  the  left  side  is  termed  the  retreating  side.  The  two 
terms  are  due  to  the  difference  in  the  relative  velocity  experienced  by  the  blade  when  the 
helicopter  flies  forward. 

A  cylindrical  coordinate  system  is  used  to  describe  any  arbitrary  position  inside  the  rotor 
disk  model  which  represents  the  RSP.  This  coordinate  system  has  the  origin  located  at  the 
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disk  centre.  The  variables  r  and  \|/  refer  to  the  radial  and  azimuthal  position  of  the  blade, 
which  are  also  used  for  the  polar  coordinates  on  the  rotor  disk.  The  RSP  coordinate  system 
will  be  further  transformed  using  the  flap  angle  (3  into  the  Local  Rotor  Frame  of  reference 
(LRF)  which  follows  the  motion  of  the  blade  path.  This  transformation  will  be  further 
discussed  in  Section  2.3.2. 


advancing  side 


Figure  2.1:  Rotor  disk  schematic  showing  definition  of  i// and  r 

Another  important  scaling  factor  is  the  rotor  disk  solidity,  a.  The  solidity  is  the  ratio  of  the 
total  blade  area  to  the  total  disk  area.  For  a  non-tapered  (constant  chord)  blade,  the  solidity 
is  given  by: 


N.c 

a  = -  [Equation  2.1] 

ttR 

In  forward  flight,  the  forward  velocity  of  the  aircraft  is  commonly  described  in  terms  of 
"advance  ratio".  Advance  ratio,  J,  is  the  ratio  of  the  blade  tip  linear  velocity  to  the  aircraft 
forward  velocity,  V . 


J  = 


V 

0)R 


[Equation  2.2] 
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2.2.2  Blade  Geometry 

A  helicopter  blade  was  traditionally  made  of  a  symmetric  airfoil  (Reference  7).  However, 
many  modern  helicopters  now  incorporate  non-symmetrical  high-lift  airfoil  shapes.  The 
lift  on  a  blade  section  is  produced  by  increasing  the  effective  Angle-Of- Attack  (AO A)  of 
the  blade  relative  to  the  blade  motion  and  local  fluid  velocity  angle.  The  blade  AOA  is 
determined  by  the  collective  pitch  input  and  the  cyclic  pitch  input  from  the  helicopter 
control  sticks.  The  collective  pitch  applies  a  constant  AOA  to  the  blade  independent  of  its 
azimuthal  position  in  the  rotor  disk  plane,  while  the  cyclic  pitch  applies  a  harmonically 
varying  AOA  on  the  blade  depending  on  its  azimuthal  position.  The  superposition  of  the 
two  pitch  inputs  can  be  described  by  the  following  equation: 

=  (^collective  +  A  COS  y/  +  B  smifT  [Equation  2.3] 

where  is  the  geometric  angle  of  attack,  is  the  collective  pitch  angle,  A  and 

B  are  the  blade  cosine  and  sine  pitch  angles. 

Eurthermore,  the  rotor  blade  is  normally  twisted  along  its  length.  The  model  will  allow  for 
a  linear  twist  to  be  accounted  for  in  the  calculation.  Compounding  the  blade  twist  angle  on 
the  collective  pitch  and  cyclic  pitch  angles  will  yield  the  following  blade  geometric  AOA: 

«g  =  ct  collective  +  Acosy/  +  B  smij/  +  ^(r)  [Equation  2.4] 

2.2.3  Rotor  Coning  and  Flapping 

Eigure  2.2  shows  a  schematic  of  the  blade  motion.  The  basic  motion  of  the  blade  is 
essentially  rigid  body  rotation  about  the  rotor  hub.  However,  most  rotor  blades  must  be 
allowed  to  flap  vertically  as  they  rotate  for  stability  reasons  (Reference  7).  The  flapping 
motion  (shown  in  Eigure  2.2  as  the  (3  direction)  is  largely  due  to  the  asymmetric  velocity 
distribution  on  the  rotor  plane  as  the  blade  travels  from  the  advancing  side  of  the  rotor  to 
the  retreating  side  when  the  helicopter  is  moving  forward.  Eurthermore,  most  modern 
helicopter  rotors  also  allow  the  blade  to  rotate  in  the  direction  of  the  disk  plane.  This 
motion  is  called  blade  "lead-lag"  (shown  in  Eigure  2.2  as  the  direction)  and  has  been 
neglected  in  the  development  of  the  current  model. 

The  asymmetric  velocity  distribution  on  the  rotor  plane  in  forward  flight  causes 
asymmetry  of  lift  (Reference  7).  During  hover,  the  lift  is  uniform  across  the  entire  rotor 
disk.  However,  in  forward  flight,  as  the  helicopter  gains  airspeed,  the  advancing  blade 
develops  greater  lift  than  the  retreating  blade  because  of  the  increased  relative  airspeed. 
This  asymmetry  of  lift  is  compensated  for  by  allowing  the  blade  to  flap.  The  increased 
relative  airspeed  (and  corresponding  lift  increase)  on  the  advancing  blade  causes  the  blade 
to  flap  upward.  On  the  other  hand,  decreasing  speed  and  lift  on  the  retreating  blade  causes 
it  to  flap  downward.  This  flapping  process  alters  the  effective  angle  of  attack  of  the  blade 
as  each  blade  rotates,  and  further  causes  the  upward-flapping,  advancing  blade  to  produce 
less  lift,  and  the  downward-flapping,  retreating  blade  to  produce  a  corresponding  lift 
increase.  The  result  is  a  balanced  lift  distribution  across  the  disk. 
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Rotor  blades  on  helicopters  flap  in  response  to  the  centrifugal  and  aerodynamic  forces  they 
experience.  The  flapping  and  coning  motion  of  the  blade  could  not  be  physically  modelled 
in  the  VBM  as  such  a  model  would  require  the  solution  to  the  blade  equation  of  motion, 
taking  into  account  the  structural  stiffness  and  response  of  the  blade  to  the  aerodynamic 
forces.  However,  if  the  blade  flapping  and  coning  motion  is  known  a-priori,  the  model  can 
account  for  the  coning  and  the  first  harmonics  by  transforming  the  velocity  components 
from  the  RSP  to  the  LRF  (see  Figure  2.3). 

In  the  current  model  development,  flapping  is  defined  to  be  positive  for  upward  motion  of 
the  blade. 


Figure  2.2:  Blade  motion  schematic  at  an  arbitrary  azimuthal  position,  xy,  on  the  rotor  disk 

The  blade  flap  harmonic  modes  can  be  decomposed  into  longitudinal  flapping  and  lateral 
flapping.  Thus,  assuming  that  the  blade  is  rigid  along  its  span,  the  blade  flap  angle,  y9(^), 
must  be  expressed  as  a  Fourier  series: 


=  Pq-  Py^cosy/  -  ■■■  [Equation  2.5] 

The  first  term  in  Equation  2.5  is  termed  the  blade  coning  angle.  Only  the  first  sine  and 
cosine  terms  in  the  equation  are  considered  in  the  current  model.  Furthermore,  the 
flapping  velocity  dp  !  dt ,  which  typically  contributes  to  the  velocity  normal  to  the  blade 
path,  has  been  neglected. 

Figure  2.3  shows  a  sketch  of  the  blade  in  flapping  and  coning  planes  and  the  definition  of 
the  rotor  TPP  and  RSP.  Note  that  while  the  rotor  disk  in  the  mesh  represents  the  RSP,  the 
rotor  disk  region  modelled  in  the  VBM  corresponds  to  the  LRF,  not  the  RSP.  The  LRF  is  a 
moving  frame  of  reference  that  follows  the  blade  path  as  it  flaps  and  cones. 
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2.3  Model  Description 

2.3.1  The  Virtual  Blade  Model 

The  numerical  model  used  for  predicting  the  momentum  sources  in  the  rotor  disk  region 
adopted  in  this  report  was  first  introduced  by  Rajagopalan  et  al.  (References  8  and  9).  Since 
then,  several  studies  have  been  carried  out  to  investigate  the  validity  of  this  model  in  a 
simplified  environment  where  accurate  experimental  data  can  be  taken.  These  studies 
(available  at  References  4  and  10)  have  shown  that  well-known,  qualitative  features  of  the 
rotor  wake  are  well  approximated  by  this  model.  Furthermore,  these  references  also  show 
that  the  numerically  predicted  flow-field  and  the  experimentally  measured  flow-field  data 
are  quantitatively  in  good  agreement. 

At  References  2  and  11,  the  numerical  algorithm  introduced  by  Zori  et  al.  (Reference  4) 
was  implemented  in  the  Fluent  environment.  Furthermore,  at  Reference  1  DSTO 
independently  developed  an  in-house  implementation  of  the  VBM  in  Fluent.  The  model 
implemented  in  OpenFOAM  follows  closely  the  numerical  algorithm  presented  at 
References  1,  2  and  4. 

The  model  implementation  in  Reference  11  addresses  several  shortcomings  of  the  previous 
model  at  Reference  4.  The  most  notable  shortcoming  is  that  accurate  aerodynamic 
predictions  are  only  possible  if  the  rotors  operate  at  desired  thrust  and  zero  moment  about 
the  hub.  This  is  attained  by  perturbing  the  collective  (thrust)  and  the  cyclic  (moments) 
blade  pitch  angles  (a  procedure  performed  by  trim  routines  embedded  in  the  VBM  model) 
until  the  desired  rotor  thrust  and  moments  are  achieved  during  the  simulation.  The 
numerical  trim  routine  implemented  in  the  OpenFOAM  VBM  model  utilises  a  Newton- 
Raphson  iterative  method  to  account  for  the  non-linear  relation  between  blade  pitch  and 
rotor  performance. 

As  previously  discussed  in  Section  2.1,  the  VBM  model  approximates  the  time-averaged 
effect  of  the  rotor  blades  in  the  flow-field  by  explicitly  introducing  momentum  sources 
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inside  the  disk  volume  swept  by  the  spinning  rotor.  This  volume  is  referred  to  as  the  rotor 
disk  region.  The  procedure  used  to  calculate  the  momentum  sources  can  be  summarised  as 
follows: 

1.  The  flow-field  around  the  rotor  disk  region  is  solved. 

2.  The  blade  forces  on  each  point  in  the  rotor  disk  region  are  calculated  using:  the  local 
fluid  velocity;  the  modelled  blade  geometric  angles;  the  blade  2D  lifting  line;  and  the 
blade  2D  drag  curve. 

3.  The  momentum  sources  imparted  by  the  blade  onto  the  fluid  are  approximated  using 
the  calculated  blade  forces  at  each  point  in  the  rotor  disk  region. 

4.  Check  convergence  and  return  to  step  1,  if  necessary. 

2.3.2  Frame  of  Reference  Transformations 

The  following  frame  of  reference  transformations  are  applied  to  transform  the  local 
velocity  vector  acting  on  each  blade  element  from  the  global  stationary  Cartesian  frame  to 
a  rotating  frame  of  reference  that  follows  the  blade  path  (termed  the  LRF): 


1.  The  Global  Cartesian  Frame  of  Reference.  The  Navier-Stokes  Equations  are  solved  in 

the  global  Cartesian  frame  of  reference  during  the  simulation.  This  frame  of  reference 
are  defined  by  the  three  orthogonal  base  vectors,  x  ,y  and  z.  The  three  components  of 
the  velocity  vector  of  the  fluid  in  this  frame  of  reference  are  denoted  as  and  . 

2.  The  RSP  Stationary  Cartesian  Frame  of  Reference.  To  account  for  the  RSP  pitch  and 
bank  angle,  the  local  velocity  vector  acting  one  each  blade  element  is  transformed  from 
the  global  Cartesian  frame  to  the  RSP  Cartesian  frame  using  the  following  equation: 


^RSP 

COS^ 

0 

sin^ 

"1 

0 

0 

V 

yRsp 

= 

0 

1 

0 

X 

0 

COS^P 

-  sin^ 

X 

V, 

^RSP 

-  sin^ 

0 

cos^ 

0 

sin^ 

cos^p 

[Equation  2.6] 


where  the  RSP  pitch  angle,  (j) ,  and  bank  angle,  (p ,  are  calculated  using  the  RSP  normal 

vector,  Zjjgp  with  respect  to  the  global  z  direction  (i.e.  (f)  =  ^  and  ^  =  0  for  a  non  tilted 
rotor  disk). 


3.  The  RSP  Rotating  Cylindrical  Frame  of  Reference.  The  local  velocity  vector  in  the 
RSP  stationary  Cartesian  frame  is  transformed  into  the  RSP  rotating  cylindrical  frame 
using  the  following  equation: 
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'RSP 

cosy/ 

sin^ 

o' 

^RSP 

RSP 

= 

-sin^ 

cos^ 

0 

X 

ypsp 

[Equation  2.7] 

V, 

^RSP 

0 

0 

1 

V, 

^RSP 

where  the  angle  y/  is  the  rotor  azimuth  angle  in  the  stationary  RSP  cylindrical  frame  of 
reference,  and  is  related  to  the  stationary  RSP  Cartesian  system  as  follows: 


'RSP 


r~2  2  y 

+  y  and  ~  tan  — 

yxj 


[Equation  2.8] 


The  X  and  y  coordinates  used  in  Equation  2.8  are  Cartesian  coordinates  in  the  stationary 
RSP  frame  of  reference. 


4.  The  LRF  Rotating  Cylindrical  Frame  of  Reference.  The  local  velocity  vector  in  the 
RSP  rotating  cylindrical  frame  is  transformed  into  the  LRF  rotating  cylindrical  frame 
using  the  following  equation: 


'LRF 

COS  P 

0 

-sin  P 

V, 

'RSP 

'^Vlrf 

= 

0 

1 

0 

X 

^Vrsp 

[Equation  2.9] 

V, 

^LRF 

sin  P 

0 

cos  P 

V, 

^RSP 

where  the  angle  (5  is  the  compounded  flapping  and  coning  angle  previously  given  by 
Equation  2.5.  Note  that  this  frame  of  reference  is  rotating  with  the  blade  and  following 
the  blade  flapping  and  coning  motion. 

Eigure  2.4  shows  a  schematic  of  the  RSP  stationary  cylindrical  frame  of  reference  and  the 
LRP  rotating  cylindrical  frame  of  reference. 


Figure  2.4:  Schematic  of  the  blade  element  in  the  RSP  stationary  cylindrical  frame  of  reference  and 
the  LRF  rotating  cylindrical  frame  of  reference 
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2.3.3  Blade  Forces  Calculation 

A  schematic  of  the  blade  element  representation  in  the  LRF  rotating  cylindrical  frame  of 
reference  is  shown  at  Figure  2.5.  It  is  important  to  note  that  the  coordinate  system  shown 
in  this  figure  is  already  in  the  LRF  rotating  cylindrical  frame  of  reference. 

The  blade  element  area  is  given  by: 

SA  =  dr{r  .Sy/)  [Equation  2.10] 

Since  the  blade  is  not  physically  modelled  in  the  VBM,  each  cell  in  the  rotor  disk  region  is 
assumed  to  represent  a  blade  element.  However,  it  is  important  to  note  that  the 
computational  cells  in  the  disk  mesh  are  in  the  RSP  frame  of  reference,  NOT  in  the  LRF 
frame  of  reference. 

Each  cell  in  the  rotor  disk  region  can  be  described  by  the  radial  position  vector  relative  to 
the  disk  origin,  r  (x,y,z)  and  the  rotor  azimuth  angle,  y/ .  As  previously  discussed  in 

Section  2.3.2(3),  the  vector  r  and  azimuth  angle  y/  are  approximated  using  the  Cartesian 
coordinates  of  each  cell  relative  to  the  rotor  disk  centre  in  the  mesh  in  the  stationary  RSP 
frame  of  reference.  The  same  vector  r  and  azimuth  angle  y/  have  been  used  for  the 
calculation  of  the  force  acting  on  each  cell  in  the  LRF  frame  of  reference.  Therefore,  it  is 
expected  that  some  errors  are  introduced  in  the  calculation  due  to  this  approximation. 
However,  this  error  was  deemed  acceptably  small  when  the  RSP  pitch  and  bank  angles  are 
small  (typically  less  than  five  degrees),  and  when  the  compounded  blade  flap  and  cone 
angles  are  also  small  (typically  less  than  five  degrees). 


Figure  2.5:  Blade  element 


A  schematic  of  the  drag  and  lift  forces  acting  on  the  blade  element  at  any  arbitrary 
coordinate  in  the  LRF  is  shown  in  Figure  2.6. 
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Figure  2.6:  Schematic  of  the  forces  acting  on  the  blade  element  in  the  LRF 


a,  is  the  induced  AOA  in  the  LRF,  which  is  given  by: 


r 


a.  =  tan 

hRF 


-1 


V  ^  V'lrf  J 


[Equation  2.11] 


where  was  previously  calculated  using  Equation  2.9.  is  the  total  relative  fluid 

velocity  with  respect  to  the  blade  tangential  velocity,  and  is  given  by: 


V 


Vlrf 


[Equation  2.12] 


where  the  first  term  in  Equation  2.12  refers  to  the  local  fluid  velocity  in  the  direction 
parallel  to  the  blade  path  as  previously  given  in  Equation  2.9,  and  the  second  term  refers 
to  the  blade  linear  velocity  component  in  the  direction  parallel  to  the  blade  path.  The 
velocity  component  acting  on  the  blade  element  in  the  direction  orthogonal  to  the  blade 
path,  is  previously  given  by  Equation  2.9. 

To  estimate  the  forces  acting  on  fluid  particles,  consider  the  forces  acting  on  the  two- 
dimensional  blade  section  shown  in  Figure  2.6.  Note  that  the  positive  rotation  of  the  airfoil 
is  in  the  positive  z-direction.  Components  of  the  blade  force  acting  in  the  normal  and 
tangential  direction  to  the  blade  chord  are  given  by  the  following  equations: 

4,,  =  f  cos  -  f,  sin  [Equation  2.13] 

Ulrf  ^  ^Frf  ^  4  cos  [Equation  2.14] 
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2.3.4  Blade  Section  Lift  and  Drag 


The  blade  sectional  lift,  /, ,  and  sectional  drag,  ,  on  each  blade  element  (seen  in 
Equations  2.13  and  2.14)  are  calculated  based  on  the  effective  AOA  seen  by  the  blade 
element  and  the  airfoil  lift  and  drag  coefficients.  Erom  Eigure  2.6,  the  effective  AOA  seen 
by  each  blade  element  ( )  is  given  by: 


'LRF 


a 


Slrf 


a. 


''LRF 


[Equation  2.15] 


Using  the  effective  AOA,  the  sectional  lift  and  drag  coefficients  can  be  obtained  as  a 
function  of  AOA  using  a  predefined  lookup  table.  The  lookup  tables  are  user  inputs  which 
can  be  obtained  using  the  two-dimensional  lifting  line  theory  for  a  given  blade  airfoil 
shape. 

It  is  important  to  note  that  this  model  neglects  any  compressibility  effect  due  to  the 
moving  blade.  The  blade  lift  coefficient  is  assumed  to  be  directly  proportional  to  the 

effective  AOA,  i.e.  Cj  oc  . 


The  sectional  forces  acting  on  the  blade  are  given  by: 


f,  =\p(U,.J"cC, 

fd  —  "^d 


[Equation  2.16] 
[Equation  2.17] 


where: 

c  is  the  chord  length  at  the  location  of  the  blade  element. 

Cl  and  Cj  are  the  sectional  lift  and  drag  coefficient  respectively,  and 

^ local  ^he  local  induced  fluid  velocity  experienced  by  the  blade  element. 


The  local  velocity  is  given  by  the  following  expression  for  each  blade  element: 


u. 


local 


IFl 

N(v'  f 

\1  V  ^LRF  / 

V  ¥  LRF  / 

[Equation  2.18] 


The  radial  fluid  velocity  component  in  the  rotor  disk  region  has  not  been  included  in 
Equation  2.18  in  accordance  to  the  BET  assumption.  and  were  previously 

calculated  using  Equation  2.9  and  Equation  2.12  respectively. 

The  blade  sectional  lift  and  drag  in  Equations  2.16  and  2.17  can  subsequently  be 
substituted  into  Equations  2.13  and  2.14  to  obtain  the  rotor  thrust  and  torque  forces  which 
are  the  forces  normal  and  parallel  to  the  rotor  disk  plane  respectively. 
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Finally  the  elemental  thrust,  torque,  and  power  on  each  blade  element  can  be  calculated 
using: 


dT  =  [Equation  2.19] 

dQ  =  N ^f^^^^rdr  [Equation  2.20] 

dP  =  COdQ  =  CO.rdr  [Equation  2.21] 

where  N is  the  number  of  blades  in  the  rotor  disk.  The  total  forces  on  the  rotor  disk  are 
obtained  by  integrating  over  the  blade  span  from  root  to  tip.  The  root  cutout  can  be 
modelled  as  a  "hole"  in  the  centre  of  the  disk. 

2.3.5  Blade  Tip  Effect 

As  previously  discussed,  at  each  spanwise  location  of  the  blade  (which  is  equal  to  the 
radial  direction  of  the  rotor  disk)  local  lift  and  drag  forces  are  computed  assuming  two- 
dimensional  flow.  This  assumption  is  violated  in  close  proximity  to  the  blade  tip  due  to 
the  presence  of  increasingly  strong  secondary  flow  around  this  area. 

To  account  for  the  loss  of  blade  lift  near  the  tip,  a  simple  correction  factor  was  applied  to 
the  force  calculations  in  the  region  near  the  edge  of  the  rotor  disk.  In  the  corrected  model, 
the  blade  lift  is  assumed  to  be  zero  for  blade  elements  that  are  located  outward  of  a  certain 
user-selected  threshold  value.  This  threshold  is  in  the  form  of  a  radial  distance  from  the 
rotor  disk  origin,  normalised  by  the  rotor  disk  radius.  For  example,  a  value  of  0.96  means 
that  from  a  normalized  span  of  0.96  outward,  the  lift  forces  are  set  to  zero  while  the  drag 
forces  are  still  accounted  for  (using  the  two-dimensional  assumption).  Hence,  using  this 
example,  the  last  four  per  cent  of  the  blade  span  produces  no  lift  (just  recirculation  around 
the  blade)  while  it  still  produces  drag.  A  tip  loss  factor  of  0.96  is  typical  for  a  helicopter 
rotor  (Reference  12). 

2.3.6  Momentum  Sources 

Figure  2.7  shows  a  typical  structured  mesh  used  for  CFD  modelling  of  a  rotor  disk  using 
the  VBM.  The  rotor  disk  is  represented  in  the  CFD  model  by  a  collection  of  cells  (in  this 
case  of  hexahedral  form).  In  the  VBM,  momentum  sources  that  represent  the  effect  of  the 
blade  forces  on  the  fluid  flow  are  introduced  in  each  of  the  computational  cells  in  the  rotor 
disk  region. 
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Figure  2.7:  Typical  structured  mesh  used  to  model  the  rotor  disk  using  the  VBM 


The  method  for  calculating  the  blade  forces  on  each  blade  element  represented  by  each  of 
the  cells  in  Figure  2.7  has  been  outlined  in  Sections  2.3.1  through  2.3.5.  It  is  important  to 
note  that  there  is  no  direct  relationship  between  the  blade  element  and  the  computational 
cell  in  the  mesh.  However,  the  method  used  to  calculate  the  forces  acting  on  the  blade 
element  can  be  applied  to  calculate  the  equivalent  blade  forces  at  each  computational  cell 
in  the  rotor  disk. 


In  this  section,  the  method  for  converting  the  calculated  instantaneous  blade  forces  into 
the  time-averaged  momentum  sources  will  be  described. 

The  forces  acting  on  each  cell  in  the  LRF  are  given  by  Equations  2.13  and  2.14.  However, 
these  calculated  forces  are  instantaneous  forces  experienced  by  the  cell  as  the  blade  is 
traversing  through  air.  In  a  time-averaged  simulation,  such  as  steady  RANS,  the  time- 
averaged  force  experienced  by  each  cell  in  the  rotor  disk  region  is  only  a  fraction  of  these 
instantaneous  forces.  Therefore,  assuming  a  constant  rotational  speed  of  the  rotor,  time¬ 
averaging  over  one  period  is  identical  to  geometric  averaging  over  an  angle  of  Itt  .  Thus, 
the  time-averaged  forces  experienced  by  each  cell  can  be  obtained  by  scaling  the 
instantaneous  forces  (Equations  2.13  and  2.14)  by  a  scaling  factor  of: 


S  =  N^Sr 


rSy/ 

Ittt 


[Equation  2.22] 


rdxLf 

where  the  ratio  -  is  the  ratio  of  the  arc  length  of  a  blade  element  to  the  circumference 

2nr 

of  the  rotor  disk,  and  Nf^  is  the  number  of  blades  in  the  rotor  disk. 
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Applying  the  scaling  factor  in  Equation  2.22  to  the  instantaneous  forces  given  by 
Equations  2.13  and  2.14  yields  the  resultant  time-averaged  forces  acting  on  each  cell  as: 

)  =  /z,,,  -S  =  N,  [Equation  2.23] 

)  =  4...  [Equation  2.24] 

Eor  a  structured  mesh  in  the  rotor  disk,  the  term  &~.r5y/  is  equivalent  to  the  blade  element 
area  SA  (refer  to  Equation  2.10).  This  assumption  is  only  valid  if  the  cell  is  of  the  form  of  a 
hexahedra,  where  the  sides  are  parallel  to  the  radial  lines  and  the  other  two  sides  are  lying 
on  concentric  circles.  Therefore,  the  mean  forces  acting  on  each  cell  can  be  calculated  as 
follows: 


=  ^(/  ) 


[Equation  2.25] 


=^(/  ) 

/cell 


SA 


cell 


[Equation  2.26] 


This  implementation  limits  the  cell  type  that  can  be  used  for  meshing  the  rotor  disk  region 
in  the  CED  model  to  only  structured  hexahedral  cells. 

The  forces  on  each  cell  given  by  Equations  2.25  and  2.26  are  forces  in  the  ERE  rotating 
cylindrical  frame  of  reference.  Therefore,  these  forces  need  to  be  transformed  back  into  the 
RSP  rotating  cylindrical  frame  of  reference  using  the  following  operation: 


'RSP 

COS  P 

0 

sin  P 

"4 

'LRF 

F 

V'rsp 

— 

0 

1 

0 

X 

F 

Wlrf 

[Equation  2.27] 

F 

^RSP  _ 

-sin  P 

0 

cos  P 

F 

^LRF 

EoIIowing  this  transformation,  the  forces  in  the  rotor  RSP  rotating  cylindrical  frame  of 
reference  need  to  be  transformed  into  the  RSP  stationary  Cartesian  frame  of  reference 
using  the  following  equation: 
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F 

^RSP 

COSlf/ 

-sin^ 

0“ 

'RSP 

F 

Vrsp 

— 

sin^ 

COSl// 

0 

X 

RSP 

[Equation  2.28] 

F^ 

^RSP  _ 

0 

0 

1 

F^ 

^RSP  _ 

The  calculated  forces  in  the  RSP  stationary  Cartesian  frame  of  reference  can  finally  be 
transformed  to  the  global  Cartesian  frame  using  the  rotor  disk  pitch  and  bank  angles  as 
follows: 


cos(-  (f) 

0 

sin(-  (f) 

“1 

0 

0 

F, 

^RSP 

Fy 

= 

0 

1 

0 

X 

0 

cos(-  (p) 

-  sin(-  (p) 

X 

F 

yRsp 

F,_ 

-  sin(-  (f) 

0 

cos(-  (f) 

0 

sin(-  (p) 

cos(-  (p) 

F^ 

^RSP  _ 

[Equation  2.29] 


Einally,  the  rotor  forces  in  the  global  Cartesian  frame  can  be  converted  into  volumetric 
momentum  sources  on  every  cell  in  the  rotor  disk  region  by  dividing  the  cell  forces  by  the 
cell  volume  as  follows: 


[Equation  2.30] 


where  \F  is  the  force  vector  in  the  global  Cartesian  frame  at  every  cell  in  the  rotor  disk 
region  as  given  by  Equation  2.29,  and  is  the  cell  volume. 

2.3.7  Rotor  Trim  Model 

According  to  Reference  4,  accurate  aerodynamic  predictions  are  only  possible  if  the  rotors 
are  operating  at  the  correct  thrust  level.  This  means  that  a  trimming  computation  is 
needed  during  the  CED  simulation  if  the  blade  parameters  necessary  to  achieve  the  correct 
thrust  level  are  not  known  a  priori.  Eurthermore,  during  a  steady  hover  or  level  flight,  the 
rotor  moments  are  generally  zero;  hence,  this  must  be  accurately  represented  by  the  VBM 
during  the  simulation. 

At  any  arbitrary  flight  mode,  the  total  thrust  and  rotor  pitching  and  rolling  moments 
acting  on  the  rotor  disk  can  be  calculated  by  integrating  the  cell  forces  across  the  entire 
rotor  disk  region  as  follows: 
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f 

thrust 

M. 


pitch 


M 


roll 


[Equation  2.31] 


The  effect  of  flapping  hinge  offset  is  neglected  from  the  moment  calculations,  shown  in 
Equation  2.31.  Since  the  relationship  between  the  rotor  aerodynamic  parameters  and  the 
blade  pitch  is  non-linear,  an  iterative  technique  is  needed  to  obtain  a  converged  trim 
result.  In  such  a  method,  the  collective  and  cyclic  pitch  angles  are  iteratively  perturbed  in 
the  simulation  in  order  to  achieve  the  desired  thrust  coefficient,  and  eliminate  the 
moments  around  the  hub.  The  updates  to  the  blade  angles,  which  are  treated  as  a  control 
input  at  each  trim  iteration,  can  be  obtained  using  a  Newton-Raphson  method  applied  to  a 
linearised  system  of  coupled  equations  relating  the  rotor  response  (i.e.  the  rotor  thrust  and 
moments)  to  the  control  vector. 

Let  the  control  input  vector  be  denoted  by  x ,  and  the  rotor  response  vector  be  denoted  by 
y ,  as  follows: 


ry 

collective  1 

F 

thrust 

X  = 

A 

,  and  y  = 

Mpuch 

B 

_  ^  roll  _ 

A  first  order  Taylor  expansion  for  the  rotor  response  about  x  can  then  be  written  as: 


T 


(x-f  Ax]=y(x]+  [/]Ax  +  ... 


[Equation  2.32] 


+  Ax] 


where  y\x  +  Ax  lis  the  rotor  response  vector  due  to  the  new  control  input  vector 


x-l- Ax 


Equation  2.32  can  then  be  re-arranged  into: 

[/]Ax  =  {y(x  -I-  Ax)-  t(x)|  [Equation  2.33] 

The  tensor  [j]  is  the  Jacobian  of  the  dependant  quantities  (response  variables  in  terms  of 
the  control  input  (i.e.  thrust,  pitching  and  rolling  moments),  and  is  given  by  the  following 
tensor: 
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da 


collective 


dA 


dF 

thrust 

dF 

thrust 

dF 

thrust 

rjfy 

^  ^  collective 

dA 

dB 

^Mpi,ch 

S^pitcl, 

SMpi,ch 

collective 

dA 

dB 

SMcoll 

dMcoii 

dB 


[Equation  2.34] 


Each  term  in  the  Jacobian  tensor  can  be  discretised  using  first  order  Taylor  expansion  for 
solving  with  the  Newton-Raphson  method.  Eor  example,  the  Jacobian  for  the  thrust  can  be 
discretised  into: 


thrust  _  ^thrust  {.^init  +  Srl2) 

^thrust  ip^init  Sr, -2) 


dy 


Sy 


[Equation  2.35] 


Equation  2.35  is  solved  for  an  initial  guess  value  of  A,B .  EoIIowing  the  initial 

solution  a  perturbed  solution  is  obtained  from  the  small  perturbation  angle  of  a  +  yjl. 
The  iterations  stop  and  an  estimate  for  the  changes  to  the  perturbed  angles 
5a collective  ’  5A,  SB  is  obtained  in  the  form  of: 


J7 

thrust 

M. 


'  pitch 


M 


roll 


(0) 
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dF 

thrust 

dF 

thrust 

dF 

thrust 

dot 

^  ^ collective 

dA 

dB 

^Mpi,ch 

QMpi,ch 

dot 

^collective 

dA 

dB 

dMcoii 

SMcoii 

dMcoii 

d(y 

_  ^  ^ collective 

dA 

dB 

1(0) 


5^ collective  ^ 

(0) 

thrust 

5A 

= 

Mpiieh 

SB 

.^roll  _ 

(1) 


[Equation  2.36] 


Note  that  for  this  method  to  work  the  Jacobian  must  be  constructed  from  a  frozen  flow- 
field  and  perturbing  the  pitch  angles  independently.  With  the  new  a  as  the  initial  guess, 
the  above  iterative  procedure  continues  until  the  target  thrust  and  moments  are  achieved, 
and  the  flow-field  is  converged. 

2.3.8  Dimensionless  Parameters 

It  is  sometimes  convenient  to  specify  the  target  thrust  and  moments  acting  on  the  rotor 
disk  by  using  a  set  of  dimensionless  parameters.  The  following  dimensionless  parameters 
are  commonly  used  to  describe  the  rotor  performance: 

Coefficient  of  Thrust:  ^  [Equation  2.37] 

P^disk  y^^disk  ) 


UNCLASSIEIED 


19 


DSTO-TR-2931 


UNCLASSIFIED 


Coefficient  of  Pitching  Moment: 


Coefficient  of  Rolling  Moment: 


C  = 

'-'Mx 


M 


pitch 


P^disk  ip^^disk  )  ^di! 

M 


disk 


roll 


Pd,.AcoR,,jR 


disk 


[Equation  2.38] 


[Equation  2.39] 


In  the  current  implementation,  the  rotor  trim  model  utilises  the  total  rotor  thrust  and 
moment  values  as  the  desired  trim  target.  However,  the  dimensionless  parameters  are 
commonly  used  for  specifying  the  desired  rotor  performance.  Therefore,  the  target  forces 
and  moments  must  be  calculated  from  the  dimensionless  parameters  using  Equations  2.37 
through  2.39. 

2.3.9  Summary 

A  VBM  model  for  modelling  the  flow  through  a  simplified  rotor  disk  in  a  RANS 
simulation  has  been  described  in  detail  in  this  section.  This  model,  which  is  derived  from 
the  well-known  BET,  accounts  for  the  time-averaged  effect  of  the  motion  of  the  blade  in  a 
rotor  disk  region  embedded  inside  a  larger  computational  domain  used  in  CED. 

The  model  introduces  volumetric  momentum  sources  in  each  computational  cell  that 
collectively  make  up  the  rotor  disk  region.  The  momentum  sources  are  computed  based  on 
the  time-averaged  blade  forces  (per  unit  cell  volume)  imparted  by  the  blade  onto  the  fluid 
as  it  traverses  through  the  air.  The  VBM  also  accounts  for  the  blade  flapping  and  coning. 
Eurthermore,  the  blade  collective  pitch,  cyclic  pitch,  and  twist  angles  are  mathematically 
modelled  in  the  VBM. 

The  model  description  presented  in  this  section  will  form  the  basis  of  its  implementation 
in  OpenEOAM,  which  will  be  presented  in  Section  3. 
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3.  Model  Implementation  in  OpenFOAM 

3.1  Overview 

This  section  describes  the  specific  implementation  of  the  VBM  in  the  OpenFOAM 
environment.  The  description  contained  in  this  Section  will  focus  on  providing  the  reader 
with  an  overview  of  the  code  structure,  as  well  as  the  integration  of  the  VBM  with  the  flow 
solver  in  OpenFOAM.  A  complete  copy  of  the  code  is  provided  at  Appendix  A. 

As  previously  described  in  Section  2,  the  VBM  essentially  introduces  momentum  sources 
in  the  cells  that  collectively  make  up  the  rotor  disk  region.  Therefore,  the  description  of  the 
implementation  of  this  model  in  OpenFOAM  will  begin  by  describing  how  these 
additional  momentum  sources  are  incorporated  into  the  global  fluid  momentum  equations 
that  are  solved  by  the  RANS  solvers.  Following  this,  a  detailed  explanation  of  the  object- 
orientation  structure  used  in  the  VBM  will  be  presented.  A  procedure  on  how  to  compile 
the  code  in  the  OpenFOAM  environment  will  be  given  at  the  end  of  this  Section. 

In  order  to  understand  the  way  in  which  the  OpenFOAM  library  and  solvers  work,  some 
background  knowledge  of  C++,  the  base  language  of  OpenFOAM,  is  required.  A 
description  of  the  C++  language,  the  object-oriented  programming  paradigm,  and  its  best 
practice  are  outside  the  scope  of  this  report.  However,  the  OpenFOAM  User  Guide 
(Reference  13)  and  Programming  Guide  (Reference  14)  provide  a  good  overview  of  the 
general  code  structure,  the  use  of  object-orientation  paradigm  in  OpenFOAM,  and  several 
base  classes  and  operators  used  in  OpenFOAM. 

The  description  contained  in  this  Section  of  the  report  shall  assume  that  the  reader  has 
some  familiarity  with  the  C++  object-oriented  paradigm,  but  minimal  knowledge  of  the 
OpenFOAM  classes  and  solvers. 

3.2  Applicable  OpenFOAM  Version 

OpenFOAM  is  continuously  updated  through  the  use  of  its  online  repository  at  Reference 
3.  The  final  version  of  the  code  developed  in  this  report  was  ensured  to  be  fully  compatible 
with  OpenFOAM  version  2.1.x  (dated  26  June  2012).  Consequently,  all  OpenFOAM  code 
described  in  this  report  refers  to  the  aforementioned  version  release. 

Due  to  potential  changes  implemented  in  the  base  OpenFOAM  code  between  version 
updates,  the  VBM  code  delivered  in  this  report  may  not  compile  or  run  with  the  later 
version.  However,  to  an  experienced  OpenFOAM  user,  relatively  minor  changes  can  be 
implemented  in  the  current  VBM  code  to  make  it  compatible  with  the  later  releases  of 
OpenFOAM. 

Similarly,  the  VBM  code  delivered  in  this  report  is  not  guaranteed  to  be  compatible  with 
any  OpenFOAM  versions  earlier  than  the  version  2.1.x  (dated  26  June  2012). 
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3.3  The  Flow  Solvers 

3.3.1  Overview  of  RANS  Solvers  in  OpenFOAM 

The  standard  OpenFOAM  distribution  includes  a  collection  of  top-level  flow  solvers. 
These  flow  solvers  are  the  top-most  level  executable  files  in  OpenFOAM,  and  are 
differentiated  based  on  the  flow  physics  that  are  being  solved.  Table  3.1  provides  a  set  of 
examples  of  the  variety  of  OpenFOAM  standard  solvers  that  are  typically  used  in  the  IRSA 
group.  Note  that  the  standard  OpenFOAM  distribution  includes  a  larger  number  of 
standard  solvers  than  that  shown  in  Table  3.1. 

Table  3.1:  List  of  standard  OpenFOAM  flow  solvers  that  are  applicable  to  the  IRSA  Group 


Basic'  CFD  Solver 

Solves  a  simple  Laplace  equation,  e.g.  tor  thermal  diffusion 

laplacianFoam 

in  a  solid 

Simple  potential  flow  solver  which  can  be  used  to  generate 

potentialFoam 

starting  fields  for  full  Navier-Stokes  codes 

Incompressible  Flow  Solvers 

Steady-state  solver  for  incompressible,  1 U  turbulent  flow,  typically  to 

boundaryFoam 

generate  boundary  layer  conditions  at  an  inlet,  for  use  in  a  simulation 

Transient  solver  for  incompressible,  laminar  flow  of  Newtonian 

icoFoam 

fluids 

Steady-state  solver  for  incompressible,  turbulent  flow  based  on  SIMPLE 

simpleFoam 

algorithm 

Steady-state  solver  tor  incompressible,  turbulent  flow  of  non-Newtonian 

SRFSimpleFoam 

fluids  in  a  single  rotating  frame 

pisoFoam 

Transient  solver  for  incompressible  flow  based  on  PISO  algorithm 

Compressible  Flow  Solvers 

rhoSimpleFoam 

simpleFoam  solver  for  compressible  flow 

Steady-state  SIMPLEC  solver  for  laminar  or  turbulent  RANS 

rhoSimplecFoam 

flow  of  compressible  fluids 

Large  time-step  transient  solver  for  compressible  flow  using 

rhoPimpleFoam 

the  PIMPLE  (merged  PISO-SIMPLE)  algorithm 

Density-based  compressible  flow  solver  based  on  central  upwind 

rhoCentralFoam 

schemes  of  Kurganov  and  Tadmor 

Heat  Transfer  and  Buoyancy  Driven  Flow  Solvers 

Steady-state  solver  for  buoyant,  turbulent  flow  of  compressible 

buoyantBaffleSimpleFoam 

fluids  using  thermal  baffles 

Steady-state  solver  tor  buoyant,  turbulent  flow  ot  incompressible  fluids 

buoyantBoussinesqSimpleFoam 

based  on  SIMPLE  algorithm  and  Boussinesq  approximation 

Steady-state  solver  tor  buoyant,  turbulent  flow  ot  compressible  fluids 

buoyantSimpleFoam 

based  on  SIMPLE  algorithm 

Combustion 

Solver  for  combustion  with  chemical  reactions  using  density 

rhoReactingFoam 

based  thermodynamics  package 

fireFoam 

Transient  Solver  for  Fires  and  turbulent  diffusion  flames 

PDRFoam 

Solver  for  compressible  premixed/partially-premixed  combustion  with 
turbulence  modelling 

dieselEngineFoam 

Solver  for  diesel  engine  spray  and  combustion 

The  VBM  code  was  developed  to  be  compatible  with  any  of  the  above  listed  flow  solvers. 
However,  further  modification  to  the  standard  flow  solvers  may  be  needed  to  implement 
the  VBM  model  in  the  solvers. 
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In  this  report,  an  example  of  how  one  may  modify  the  off-the-shelf  steady-state 
compressible  flow  solver,  rhoSimpleFoam,  to  include  the  VBM  calculation  in  the 
simulation  will  be  provided.  However,  the  same  procedure  can  be  applied  to  any  of  the 
above  listed  flow  solvers. 

3.3.2  Overview  of  the  rhoSimpleFoam  Solver 

The  standard  rhoSimpleFoam  source  code  can  be  found  in  the  following  path: 

$FOAM_APPLICATIONS/ solvers/ compressible/rhoSimpleFoam 

rhoSimpleFoam,  like  any  other  flow  solver  in  OpenFOAM,  is  largely  procedural  since  it 
is  a  dose  representation  of  solution  algorithms  and  equations,  which  are  procedural  in 
nature  (Reference  13).  Therefore,  users  do  not  necessarily  need  a  deep  knowledge  of 
object-oriented  paradigm  and  C++  programming  to  write  a  solver  but  should  know  the 
principles  behind  object-oriented  paradigm  and  classes,  and  to  have  a  basic  knowledge  of 
some  C++  code  syntax.  An  understanding  of  the  underlying  equations,  models  and 
solution  method  and  algorithms  is  deemed  to  be  far  more  important  in  developing  new 
flow  solvers  in  OpenFOAM. 

The  main  implementation  of  rhoSimpleFoam  is  contained  in  the  file  rhoSimpleFoam .  C. 

As  the  name  implies,  the  solution  algorithm  is  based  on  the  Semi-Implicit  Pressure-Linked 
Equation  (SIMPLE)  algorithm  (Reference  13)  which  is  shown  graphically  in  Figure  3.1. 

As  shown  in  Figure  3.1,  the  algorithm  basically  consists  of: 

1.  assembling  of  the  discretised  momentum  equations  into  a  matrix, 

2.  solving  the  momentum  equations  by  first  treating  the  pressure  gradient  term 
explicitly, 

3.  solving  the  pressure  equation  based  on  the  computed  momentum  field,  and 

4.  computing  the  pressure-corrected  momentum  field  for  the  next  flow  iteration. 

In  this  implementation,  the  additional  momentum  sources  that  are  introduced  by  the  VBM 
will  be  incorporated  explicitly  into  the  momentum  matrix  [■^[U]].  The  assembling  of  the 
momentum  matrix  is  contained  in  the  file  UEqn .  H  which  is  reproduced  in  Figure  3.2. 

The  momentum  matrix,  UEqn,  assembled  in  the  code  in  Figure  3.2  incorporates  both  the 
convective  term  and  diffusive  terms  in  the  momentum  equation;  however,  no  source  terms 
are  present  in  the  above  code. 
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Start  time  step 


New  p,  U,  <t> 


p,  U,  4) 


Momentum  matrix  (M[U1] 


I  Under-relax  [A4[Qll 
Solve  momentum  [M[U]]  =  -Vp 


Evaluate  H(U),  A 


Pressure  corrector  V»— Vp  =  V 
A 


(?) 


Under- relax  p 


Momentum  corrector 
and  flux  corrector 


0  =  Sr.[(HM)f-(lM)f(Vp)f] 


End  time  step 


Figure  3.1:  Implementation  of  the  SIMPLE  algorithm  in  rhoS  imp  le  Foam 


/ /  Solve  the  Momentum  Equation 

tmp<fvVectorMatrix>  UEqn 
( 

fvm : : div {phi ,  U) 

+  turbulence- >divDevRhoReff (U) 

)  ; 

UEqnO  .  relax  0  ; 

solve(UEqn()  ==  - fvc : : grad (p) ) ; 


Figure  3.2:  UEqn.H  in  rhoSimpleFoam 

In  OpenFOAM,  there  already  a  C++  class  exists  that  allows  generic  source  terms  to  be 
added  to  the  momentum  equation.  This  class  is  called  "basicSource"  class,  and  its 
source  code  lives  in  the  following  path 

$FOAM_SRC/ f initeVolume/ cf dTools/general/ f ieldSources/basicSources 

The  class  constructor  to  the  basicSources  class  will  be  described  later  in  Section  3.3.4. 
However,  it  is  useful  to  know  at  this  stage  that  the  UEqn .  H  can  be  modified  as  shown  in 
Figure  3.3  to  incorporate  a  source  term  in  the  momentum  equation.  Furthermore,  it  is 
equally  important  to  note  at  this  stage  that  the  basicSource  class  is  an  "abstract  class", 
which  means  it  contains  no  specific  implementation  of  the  source  terms  that  are  to  be 
introduced  in  the  momentum  equation.  This  specific  implementation  will  be  derived  from 
the  VBM  implementation  as  described  in  Section  3.3.5. 
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//  Solve  the  Momentum  Equation 

tmp<fvVectoriyiatrix>  UEqn 
( 

fvm : : div {phi ,  U) 

+  turbulence- >divDevRhoReff (U) 

sources (rho,  U)  //  source  terms 

)  ; 

UEqnO  .  relax  0  ; 

sources . constrain (UEqn () ) ; 

solve  (UEqnO  ==  -  fvc  :  :  grad  (p)  )  ; 

Figure  3.3:  Modified  UEqn.H  in  rhoSimpleFoam  with  basicSource  term 

The  "sources"  object  added  to  the  modified  UEqn.H  shown  in  Figure  3.3  needs  to  be 
instantiated  in  the  rhoSimpleFoam  solver.  This  can  be  done  by  adding  the  following  line 
to  the  last  line  of  the  createFields .  H  file  located  in  the  rhoSimpleFoam  source 
directory: 

lObasicSourceList  sources (mesh) ; 

From  the  above  example,  a  new  class  was  constructed,  lObasicSourceList,  which  is 
derived  from  both  a  List  class  and  basicSource  class  (see  Section  3.3.4)  in  order  to 
accommodate  the  need  to  have  multiple  sources  in  the  simulation  (such  as  having  multiple 
rotor  disks). 

No  other  modification  is  required  since  the  VBM  implementation  will  be  called  by  the 
instantiated  basicSource  class  object  during  solver  execution.  Note  that  the 
basicSource  class  can  also  be  used  to  introduce  thermal  energy  source  terms  in  the 
energy  equation. 

3.3.3  Creating  a  New  rhoSimpleSourceFoam  Solver 

It  is  considered  best  practice  to  copy  the  standard  rhoSimpleFoam  solver  code  and  place 
the  user-modified  version  in  a  new  directory,  typically: 

$FOAM_USER_APP/ rhoSimpleSourceFoam 

New  names  are  needed  for  the  directory  and  relevant  .  C  files  to  avoid  ambiguity  with  the 
standard  solver.  In  this  example,  the  rhoSimpleFoam. C  has  been  renamed  to 
rhoSimpleSourceFoam .  C,  which  will  also  be  the  executable  name  of  the  new  solver. 

The  modifications  previously  shown  in  Section  3.3.2  can  then  be  applied  to  the  source  files 
in  the  $FOAM_USER_APP/rhoSimpleSourceFoam. 

A  set  of  programming  code  files  in  UNIX/ Linux  systems  is  often  organised  and  delivered 
to  the  compiler  using  the  standard  UNIX  "make"  utility.  OpenFOAM,  however,  is 
supplied  with  a  specialised  "wmake"  compilation  script,  that  is  based  on  make  but  is 
considerably  more  versatile  and  specific,  to  compile  and  link  the  code  to  the  existing 
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OpenFOAM  library.  The  process  of  compiling  a  new  code  or  library  in  OpenFOAM  using 
the  wmake  script  is  given  at  Reference  14. 

OpenFOAM  applications  are  organised  using  a  standard  convention  that  requires  the 
source  code  of  each  application  to  be  placed  in  a  directory  whose  name  is  that  of  the 
application.  The  top  level  source  file  takes  the  application  name  with  the  .  C  extension. 
This  convention  must  be  adhered  to  when  creating  new  solvers  or  applications  in 
OpenFOAM.  For  example,  the  source  code  for  the  newly  created  rhoSimpleSourceFoam 
solver  would  reside  in  a  directory  rhoSimpleSourceFoam  and  the  top  level  file  would 
be  rhoSimpleSourceFoam.  C  as  shown  in  Figure  3.4.  The  directory  must  also  contain  a 
"Make"  sub-directory  containing  two  files,  "options"  and  "files"  . 

I  '  ^1  $FOAM_USER_APP /  rhoSimpleSourceFoam 
_  rhoSimpleSourceFoam.C 
_  HeaderFiles.H 
-  I  Make 

-  files 
_  options 

Figure  3.4:  Directory  structure  for  an  application  in  OpenFOAM 


The  final  step  that  needs  to  be  done  prior  to  compiling  the  new  solver, 
rhoSimpleSourceFoam,  is  to  modify  the  Make/files  and  Make/options  to  include 
the  entries  shown  in  Figure  3.5. 


$  cat  Make/files 

rhoSimpleSourceFoam . C 

EXE  =  $  {FOA]yi_USER_APPBIN) /rhoSimpleSourceFoam 

//  The  EXE  variable  determines  where  the  new  executable  binary  will  be 
//  placed.  It  is  important  to  use  $ (FOAM_USER_APPBIN)  path  instead  of 
//  the  standard  $ (FOAMAPPBIN)  for  revision  control. 


$  cat  Make/options 
EXE_INC  =  \ 

-1$ (LIB_SRC) /thermophysicalModels/basic/lnInclude  \ 

-1$ (LIB_SRC) /turbulenceModels  \ 

-1$ (LIB_SRC) /turbulenceModels/compressible/RAS/RASModel  \ 
-1$ (LIB_SRC) /finiteVolume/cfdTools  \ 

-1$ {LIB_SRC) /f initeVolume/lnInclude  \ 

-1$ (LIB_SRC) /meshTools/lnInclude 

EXE_LIBS  =  \ 

-IbasicThermophysicalModels  \ 

-Ispecie  \ 

-IcompressibleTurbulenceModel  \ 

-IcompressibleRASModels  \ 

-If initeVolume  \ 

-ImeshTools 


Figure  3.5:  Modified  Make/files  and  Make/options  for  compiling  rhoSimpleSourceFoam 
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Finally  the  new  rhoSimpleSourceFoam  solver  can  be  compiled  by  executing  wmake 
from  the  code  parent  directory  using  the  following  commands: 

$  cd  $FOAiyi_USER_APP/rhoSimpleSourceFoam 
$  wmake 

3.3.4  The  basicSource  Class 

The  momentum  sources  introduced  by  the  VBM  will  be  implemented  in  the  flow  solver 
through  the  use  of  the  class  basicSource.  Therefore,  before  the  newly  developed  VBM 
model  can  be  introduced,  it  is  important  for  the  reader  to  first  understand  the 
implementation  of  the  basicSource  class  in  OpenFOAM. 


The  new  class  containing  the 
implementation  of  the  VBM  in 
OpenFOAM. 


mesh__  seleclionModeTypeNames_ 


coeffs_  ^ 
X  diet,  , 

^  / 


applied_  ✓  points.. 


'•  cellSetName_ 
name 


basicSource  -  ' 


Figure  3.6:  Class  hierarchy  of  basicSource  class  in  OpenFOAM 

Figure  3.6  shows  the  basicSource  class  hierarchy.  The  hierarchy  diagram  has  been 
generated  using  doxygen.  Further  details  on  doxygen  legend  can  be  found  at  Reference  15. 
As  seen  from  this  figure,  the  VBM  code  will  be  implemented  as  a  new  class,  called 
"rotorDiskSource",  which  will  inherit  attributes  from  the  basicSource  class.  Since 
the  basicSource  class  is  an  abstract  class  with  no  implementation  (by  using  virtual 
functions),  the  implementation  of  the  VBM  using  this  class  in  the  flow  solver  can  be  made 
by  adding  the  VBM  libraries  into  the  runTimeSelectionTable  of  this  class.  This  means 
that  the  rotorDiskSource  class  (and  all  other  classes  derived  from  the 
rotorDiskSource  class)  that  contains  the  specific  implementation  of  the  VBM  will 
contain  a  series  of  functions  that  can  be  "hooked-up"  with  the  virtual  functions  in  the 
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basicSource  class.  Virtual  functions  that  are  used  in  the  implementation  of  the 
rotorDiskSource  class  are  listed  below: 

•  virtual  void  isActiveO.  This  virtual  function  reads  the  input  dictionary  of 
the  source  model  and  determines  if  the  source  is  active  during  a  simulation. 

•  virtual  bool  read  (const  dictionary  &dict).  This  virtual  function 
reads  the  input  dictionary  of  the  source  model  for  relevant  parameters  to  be  used 
in  the  model  implementation. 

•  virtual  void  addSup  ( fviyiatrix<type>  &UEqn,  const  label  fieldl). 
This  virtual  function  adds  the  momentum  sources  explicitly  into  the  passed 
momentum  matrix. 


Interested  users  and  readers  are  recommended  to  further  explore  the  functionality 
provided  by  the  basicSource  class  by  reviewing  its  source  code. 

One  of  the  major  advantages  of  using  the  basicSource  class  as  a  template  abstract  class 
for  deriving  the  VBM  library  is  that  multiple  source  term  objects  of  different  kind  can  be 
spawned  in  the  simulation.  This  means  that  the  simulation  can  include  multiple  rotor 
disks,  multiple  heat  source  terms,  and  multiple  porosity  terms. 

The  basicSource  class  is  a  registeredlOObj  ect  class,  which  means  any 
basicSource  object  spawned  during  runtime  is  automatically  tracked  globally  by  the 
solver.  However,  since  the  basicSource  class  is  an  abstract  class,  the  specific 
implementation  of  the  source  term  (e.g.  VBM  or  heat  source  term)  can  vary  depending  on 
the  specific  classes  that  are  derived  from  this  basicSource  class.  Some  examples  of  such 
derived  classes  are  rotorDiskSource  (VBM),  actuationDiskSource  (momentum 
sink)  and  porousMedia  (porosity  momentum  sink). 

3.3.5  Overview  of  the  VBM  Library  Classes 

The  VBM  code  developed  in  OpenFOAM  comprises  multiple  C++  classes.  The  file 
structure  grouped  by  the  class  name  is  shown  in  Figure  3.7.  Calculation  of  the  blade  forces 
and  momentum  source  terms  using  the  methodology  outlined  in  Section  2  is  implemented 
in  the  main  class,  rotorDiskSource.  A  hard  copy  of  all  the  source  code  included  in 
Figure  3.7  is  available  from  Appendix  A,  sorted  by  the  class  hierarchy. 
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[rotorDiskSource] 


—  [Make] 
I  —  files 


\ - options 


—  [bladeModel] 

I  —  bladeModel.C 
\ - bladeModel.H 


■—  [profileModel] 

I 

I  —  [lookup] 

I  I - lookupProfile.C 

I  \ - lookupProfile.H 

I 

I - profileModel.C 

I - profileModel.H 

I - profileModelList.C 

I  —  profileModelList.H 

I 

\ - [series] 

I - seriesProfile.C 

\ - seriesProfile.H 


—  rotorDiskSource.C 

—  rotorDiskSource.H 

—  rotorDiskSourcel.H 

—  rotorDiskSourceTemplates.C 

- [trimModel] 

I  —  [fixed] 

I  I - fixedT  rim.C 

I  \ - fixedTrim.H 

I  —  [targetForce] 

I  I - targetForceTrim.C 

I  \ - targetForceTrim.H 


A  class  for  constructing  the  blade  geometrical 
angle  of  attack  as  a  function  of  the  disk  radial 
and  azimuthal  positions. 

An  abstract  class  for  different  methods  of 
constructing  the  Cl  and  Cd  lookup  tables.  It 
allows  for  easy  addition  of  new  methods  of 
constructing  the  blade  Cl  and  Cd  curves. 


The  class  "lookup"  inherits  from  profileModel 
and  uses  linear  interpolation  to  construct  the  Cl 
andCd  curves. 


The  class  "series"  inherits  from  profileModel 
and  uses  a  harmonic  function  to  construct  the  Cl 
and  Cd  curves. 

The  main  class  for  the  VBM  implementation. 
This  class  inherits  from  the  basicSource  class. 


Classes  that  inherit  from  the  abstract  class 
trimModel,  and  contain  different 
implementations  of  the  rotor  trim  model,  i.e. 
fixed:  No  trimming 
targetForce:  Perturb  the  blade  AOA  to 
achieve  the  user  specified  target  forces 
and  moments 


\-- 

[ttimModel] 

1- 

—  trimModel.C 

1- 

—  trimModel.H 

\- 

—  trimModelNew.C 

An  abstract  class  for  different  rotor  trim 
models.  It  allows  for  easy  addition  of  new  trim 
models. 


Figure  3.7:  Overview  of  the  directory  and  file  structure  of  the  VBM  source  code  in  OpenFOAM 


As  previously  discussed,  the  rotorDiskSource  class  must  inherit  from  the  abstract  base 
class  basicSource  in  order  to  be  implemented  in  the  flow  solvers.  This  is  reflected  in  the 
file  rotorDiskSource.H  (Appendix  A.2.1),  which  includes  the  class  declaration 
statement  shown  in  Figure  3.8.  The  rotorDiskSource  .H  also  contains  a  declaration  for 
the  class  constructor  function,  all  private  and  public  data  members,  as  well  as  all  the 
private  and  public  member  functions  of  the  rotorDiskSource  class.  It  is  important  to 
note  that  because  this  class  inherits  from  the  basicSource  class,  any  change  in  the 
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constructor  of  the  basicSource  class  in  a  later  release  of  OpenFOAM  must  also  be 
propagated  to  this  class. 


$cat  rotorDiskSource . H 

class  rotorDiskSource 
public  basicSource 

{ 


Figure  3.8:  Class  declaration  in  rotorDiskSource.H  showing  inheritance  from  basicSource 

In  order  for  the  rotorDiskSource  class  to  "hook-up"  with  the  basicSource  class,  the 
following  two  criteria  must  be  satisfied: 

1.  The  class  must  contain  implementations  of  the  basicSource  class  virtual 
functions  listed  in  previously  in  Section  3.3.4,  and 

2.  The  class  must  inherit  from  the  basicSource  class,  have  a  specific  typeName, 
and  contain  an  implementation  that  allows  for  the  class  to  be  registered  in  the 
runTimeSelectionTable  of  the  basicSource  class. 

The  implementation  of  the  two  criteria  above  in  the  rotorDiskSource  will  be  discussed 
in  the  following  paragraphs. 

Implementation  of  the  basicSource  virtual  functions  in  rotorDiskSource. 

The  implementation  of  the  virtual  function  addSup  ( )  which  returns  the  momentum 
sources  to  the  flow  solvers  is  shown  in  Figure  3.9.  Note  that  the  addSup  ( )  in  the 
rotorDiskSource  actually  calls  another  protected  internal  member  function  calculate  ( ) 
included  in  the  rotorDiskSource.  Similarly,  the  implementation  of  the  virtual  functions 
read  ( )  and  writeData  ( )  can  also  be  found  in  the  rotorDiskSource  .  C . 

Adding  the  rotorDiskSource  class  to  the  runTimeSelectionTable. 

The  basicSource  is  an  abstract  class  that  allows  for  new  source  models  to  be  introduced 
and  registered  to  its  runTimeSelectionTable.  This  mechanism  allows  the  user  to  select 
the  different  source  models  to  be  run  with  the  flow  solvers  without  re-compiling  the  entire 
base  code  prior  to  each  run.  In  the  case  of  the  rotorDiskSource,  this  process  is  done 
using  a  static  member  function  in  the  rotorDiskSource .  C  as  shown  in  Figure  3.10.  Note 
that  this  process  is  generic  in  OpenFOAM,  and  can  be  copied  for  adding  any  new  source 
models  or  boundary  conditions  in  the  future. 
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$  cat  rotorDiskSource . C 

void  Foam ::  rotorDiskSource  ::  addSup  { fviyiatrix<vector>&:  eqn,  const  label  fieldl) 

//  The  momentum  matrix  UEqn  is  passed  by  reference  to  this  class 
//  from  the  basicSource  class. 

{ 

const  volVectorFieldS:  U  =  eqn.psiO; 
const  vectorField  Uin  =  inf lowVelocity (U) ; 

//Initiate  the  rotor  trim  routine 

trim_->correct {Uin,  force); 

//The  blade  forces  and  momentum  sources  are  calculated 

calculate (Uin,  trim_- >alphag () ,  force); 


//  add  source  to  rhs  of  UEqn.  The  object  "force"  was  returned  by  the 
//  calculate  0  function  and  is  already  in  the  unit  of  force  per  unit  volume 

eqn  -=  force; 

} 


Figure  3.9:  Implementation  of  the  virtual  void  addSupQ  in  the  rotorDiskSource  class 


$  cat  rotorDiskSource . C 

using  namespace  Foam :: constant ; 

namespace  Foam 

{ 

defineTypeNameAndDebug (rotorDiskSource,  0) ; 

addToRunTimeSelectionTable (basicSource ,  rotorDiskSource,  dictionary) ; 

} 


Figure  3.10:  Adding  rotorDiskSource  class  to  the  basicSource  runTimeSelectionTable 

3.4  The  VBM  Library  in  OpenFOAM 

3.4.1  The  rotorDiskSource  Class 

The  rotorDiskSource  class  encapsulates  both  data  and  member  functions  that  are 
needed  to  implement  the  VBM.  The  private  data  in  this  class  are  the  variables  or 
parameters  (e.g.  rotor  RPM,  blade  pitch  angle,  etc.)  that  are  needed  for  the  VBM 
calculation.  These  data  are  not  available  for  access  from  outside  of  this  class. 

The  private  data  have  also  been  designed  to  be  read  as  user  inputs,  which  means  that 
when  the  solver  rhoSimpleSourceFoam  is  run,  the  basicSource  object  in  the  solver 
will  look  for  a  "dictionary"  file  in  the  case  directory  structure.  In  the  case  of  the 
rotorDiskSource  model,  the  dictionary  file  for  the  source  is  called 
sourceProperties,  and  must  be  placed  in  the  constant  directory  of  the  case.  An 
example  of  a  sourceProperties  file  is  given  at  Appendix  B.2.5.  This 
sourceProperties  file  is  only  read  at  the  start  or  restart  of  a  simulation. 
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A  flowchart  showing  the  implementation  of  the  rotorDiskSource  class  in  the 
OpenFOAM  rhoSimpleSourceFoam  solver  is  shown  in  Figure  3.11.  However,  the 
rotorDiskSource  class  has  been  written  as  a  generic  class  that  can  readily  be 
implemented  in  any  of  the  other  OpenFOAM  flow  solvers  (previously  listed  in  Table  3.1) 
by  following  the  method  previously  outlined  in  Sections  3.3.2  through  3.3.3. 

The  class  declaration  and  definition  for  rotorDiskSource  is  given  in  the 
rotorDiskSource .  H.  The  main  implementation  of  the  class  is  given  in  the 
rotorDiskSource .  C.  The  bulk  implementation  of  the  BET  is  given  in  the 
Foam:  :  rotorDiskSource  :  :  calculate  ()  function  in  rotorDiskSource  .  C. 


A  notable  feature  in  the  code  structure  is  that  calculation  of  the  local  blade  geometric  AOA 
is  not  implemented  inside  the  rotorDiskSource  class,  but  in  a  separate  trimModel 
class  (refer  to  Figure  3.13).  This  allows  the  future  addition  of  a  new  trim  model  while 
avoiding  significant  re-structure  of  the  rotorDiskSource  class.  Further  description  of 
the  trimModel  class  will  be  given  in  Section  3.4.3. 

Other  features  of  the  rotorDiskSource  class  that  allow  for  ease  of  future  expansion  are  as 
follows: 

1.  Addition  of  new  Lifting  Line  Models  (in  profileModel  class).  Currently  two 
different  models  are  implemented,  i.e: 

a.  using  a  Lookup  Table  (profileModel :  :  lookupProf  ile  class),  and 

b.  using  Fourier  Series  (profileModel :  :  seriesProf ile  class).  The  series 
definition  is  hard-coded  in  the  seriesProfile.C  file,  and  is  defined  by 
the  following  series  equation: 


/=1 


[Equation  3.1] 


n  /  N 

1=1 

2.  Addition  of  new  blade  geometric  models  (in  bladeModel  class).  Currently  the 
blade  can  only  be  tapered  linearly  (i.e.  the  blade  chord  varies  linearly  with  the  cell 
radial  distance  from  the  rotor  disk  origin).  The  model  also  accommodates  multiple 
taper  angles  along  the  blade  radius.  Future  blade  models  may  allow  the  variation 
of  the  blade  chord  along  the  radius  to  be  described  using  a  more  complex  function. 
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Frame 


NOTE: 

1.  Shaded  boxes  indicate  separate  ciasses 

Figure  3.11:  Implementation  of  the  VBM  using  rotorDiskSource  class  and  rhoSimpleSourceFoam 
solver  in  OpenFOAM 
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3.4.2  The  rotorDiskSource  Input/Output  (lO) 

In  the  current  implementation,  the  user  must  specify  the  rotor  characteristics  as  input 
using  the  sourceProperties  (Appendix  B.2.5)  file,  which  must  be  placed  in  the 
constant  directory  of  each  case.  This  file  is  read  during  the  class  construction  by  the 
function  Foam:  :  rotorDiskSource ::  read  () .  Any  changes  made  by  user  to  the 
sourceProperties  file  will  be  monitored  and  effected  continuously  during  runtime  at 
each  iteration. 

The  rotorDiskSource  output  consists  of  the  following: 

1.  Field  variable  data  output.  In  the  current  implementation,  the  lift  and  drag  forces 
per  unit  cell  volume  are  written  out  for  post-processing  as  a  vector  field  data  type. 
The  body  forces  can  be  visualised  using  paraview  using  a  similar  filter  to  that 
used  to  visualise  the  velocity  field. 

2.  RunTime  console  output.  In  the  current  implementation,  the  rotor  disk  global 
pitching  and  rolling  moments,  and  the  total  thrust  is  printed  to  the  screen  of  the 
running  Linux  shell.  An  example  of  this  output  is  given  in  Figure  3.12. 


Additional  data  quantities,  such  as  cell  inflow  angle,  the  cell's  cylindrical  coordinate,  and 
the  cell's  effective  AO  A,  can  be  written  out  using  the  provided  templated  function 
Foam:  :  RotorDiskSource  :  :  writeField  ( ) ,  which  is  implemented  in  the  source  file 
rotorDiskSourceTemplates . C. 


#  using  rotorDiskSource  20120822  # 


Rotor  gometry: 

-  disk  diameter 

-  disk  area 

-  origin 

-  r-axis 

-  psi-axis 

-  2-axis 

-  disk  pitch  angle 

-  disk  bank  angle 


=  0.913296076595 
=  0.655108244928 

=  (0.456990799656  -1. 92913 581591e-06  0.137099133412) 
=  (0.997493603616  0.00251125786471  0.070712122927) 

=  (0  0.999369980053  -0.0354914492492) 

=  (-0.0707567010601  0.0354024936091  0.996865162748) 

=  -2.02883742132 
=  -4.05745076975 


Starting  time  loop 


Time 


1 


rotorDisk  output: 

min/max(AOA)  =  -179.933747105,  179.968762893 

min/max(induced  aoa)  =  -179.693239706,  179.962079027 

Effective  blade  drag  =  -0.25237819429 

Effective  blade  lift  =  79.3791611656 

Total  Thrust  =  78.4210012931 

Total  Pitching  Moment  =  -0.0259606681894 

Total  Rolling  Moment  =  -3.48725183296 


Figure  3.12:  Linux  shell  output  of  rotorDiskSource  during  runtime 
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3.4.3  The  Rotor  trimModel  Class 

The  trimModel  class  is  an  abstract  class  that  carries  out  the  blade  trimming  calculation 
required  by  the  rotorDiskSource.  The  trimModel  class  is  not  derived  from  the 
rotorDiskSource.  A  private  object  called  "trim_"  of  class  type  trimModel  is 
instantiated  inside  the  rotorDiskSource  class  during  its  construction.  This  trim_  object 
acts  as  the  conduit  between  the  trimming  routine  and  the  rotorDiskSource  class  during 
the  calculation  of  the  rotor  forces. 

The  implementation  of  the  trimModel  as  an  abstract  class  allows  for  different  trim 
models  to  be  added  in  the  future  without  needing  to  alter  any  other  part  of  the  code. 
Currently,  two  classes  are  derived  from  the  trimModel,  which  are  user-selectable  from 
the  sourceProperties  file.  The  two  sub-classes  provide  two  different  trimming 
algorithms,  as  described  below: 

1.  trimModel fixedTrim  class.  The  fixedTrim  calculates  the  compounded 
blade  geometric  AOA  variation  with  respect  to  cell  radial  and  azimuthal  position 
based  on  constant  blade  collective  pitch  angles  and  cyclic  pitch  coefficients.  These 
coefficients  must  be  provided  by  the  user  in  the  sourceProperties  file.  The  use 
of  this  class  is  equivalent  to  an  "untrimmed"  VBM  model. 

2.  trimModel:  :  targetForceTrim  class.  The  targetForceTrim  class  perturbs 
the  local  blade  geometric  AOA  at  a  frozen  flow  state  (at  each  flow  solver  iteration) 
to  find  a  combination  of  blade  collective  pitch  angles  and  cyclic  pitch  coefficients 
that  will  return  the  global  thrust  and  moments  on  the  rotor  disk  that  match  the 
user-specified  target  rotor  thrust  and  moments.  To  use  this  trim  model,  the 
following  parameters  must  be  specified  in  the  sourceProperties  file: 

a.  The  target  global  rotor  thrust,  rolling  and  pitching  moments. 

b.  The  initial  guess  of  the  blade  collective  pitch  angle  and  cyclic  pitch 
coefficients  (refer  to  Equation  2.4). 

c.  The  interval  (in  flow  iterations)  in-between  trimming  routines. 

d.  The  angles  by  which  the  local  blade  AOA  needs  to  be  perturbed  during 
trimming.  The  default  value  is  0.05  degree. 

e.  The  under-relaxation  factor  for  the  newly  calculated  AOA  during  trimming. 
Note  that  this  factor  should  be  kept  at  one  unless  the  trimming  routine  is 
unable  to  find  a  trimmed  solution  within  its  iteration  limits. 

The  maximum  number  of  iterations,  and  the  minimum  force  and  moments  residuals 
allowed  during  trimming  before  a  solution  is  deemed  converged  (or  fully  trimmed)  are 
not  user-specifiable.  Currently,  these  are  set  to  default  values  of  50  and  1x10  *  for  the 
maxi  ter  and  residuals  tolerance  respectively.  These  values  are  hard-coded  in  the 
constructor  function  of  the  trimModel :  :  targetForceTrim  class,  which  can  be  found 
in  the  targetForceTrim.  C  file. 
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A  flowchart  showing  the  implementation  of  the  trimming  routine  in  the 
targetForceTrim  class  is  shown  in  Figure  3.13.  It  shows  that  the  targetForceTrim 
class  uses  the  Foam :  :  rotorDiskSource  :  :  calculate  ( )  function  to  calculate  the  local 
forces  and  moments.  This  is  done  to  avoid  any  coding  repetition  in  the  two  classes.  Note 
that  the  trimming  process  shown  in  the  flowchart  in  Figure  3.13  occurs  at  a  "frozen"  flow 
state,  meaning  the  flow  iteration  is  not  progressed  during  the  trimming  loop. 


2.  dotted  lines  indicate  information  request, 
NOT  process  flow 


New  blade 
geometric 
AOA 


TRIMMING 


Figure  3.13:  Implementation  of  the  targetForceTrim  model  in  the  rotorDiskSource  class 


The  targetForceTrim  class,  if  activated,  will  print  out  a  set  of  messages  to  the  screen  of 
the  running  Linux  shell.  An  example  of  this  output  is  given  in  Figure  3.14. 
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Selecting  source  model  type  rotoroiskl 

Source:  mamrotor 

-  selecting  cells  using  cellzone  fluid-rot 

-  selected  6000  cellCsj  with  volume  0.00604828452624 


Selecting  trimModel  targetForcerrim 

Constructing  blade  protiles: 

-  creating  series  profile  profilel 

-  creating  lookup  profile  profile2 


#  using  rotorDi skSource  20120822  # 


Rotor  gometry: 

-  disk  diameter 

-  disk  area 

-  origin 

-  r-axis 

-  psi-axis 

-  2-axis 

-  disk  pitch  angle 

-  disk  bank  angle 


0.913296076595 

0.655108244928 

(0.456990799656  -1. 92913581591e-06  0.137099133412) 
(0.997493603616  0.00251125786471  0.070712122927) 

(0  0.999369980053  -0.0354914492492) 
(-0.0707567010601  0.0354024936091  0.996865162748) 
-2. 02883742132 
-4. 05745076975 


Time  =  5 


rotoroisk  output: 

min/max(AOA)  =  -179.890247612,  179.620924285 

min/max(induced  AOA)  =  -179.98953209,  179.472340218 

Effective  blade  drag  =  -4.21274094654 

Effective  blade  lift  =  73.834737881 

Total  Thrust  =  72.9476219359 

Total  Pitching  Moment  =  0.000306500372063 

Total  Rolling  Moment  =  -0.102609832824 


targetForceTrim:  Target  Force  and  Moments 
Target  Thrust  =72.8 

Target  pitching  Moment  =  0 

Target  Rolling  Moment  =  0 

iscompressible  =  0 

targetForceTrim:  converged  in  5  iterations 
residual  =  8. 73298125566e-13 

new  pitch  angl es : 

alphac  =  7.77296261464 
A  =  0.190790918667 

B  =  -1. 5216988784 


New  blade  pitch  to  be  used  in 
the  next  flow  iteration 


(collective  and  cyclic) 


Figure  3.14:  Linux  shell  output  of  targetForceTrim  class  during  runtime 


3.5  Compiling  the  Code 

The  steps  required  to  compile  rotorDiskSource  as  a  non-executable  library  in 
OpenFOAM  differs  to  that  required  to  compile  an  executable  solver  (e.g. 
rhoSimpleSourceFoam).  A  set  of  instructions  on  how  to  compile  the 
rotorDiskSource  will  be  given  in  the  following  paragraphs. 

3.5.1  Preparation 

Prior  to  code  compilation,  all  the  VBM  library  source  codes  (previously  shown  in  Figure 
3.7)  can  be  placed  at  any  location  on  the  machine  while  maintaining  the  directory  structure 
and  naming;  however,  it  is  recommended  that  the  source  codes  are  placed  at  the  following 
standard  path,  which  is  separate  from  the  standard  OpenFOAM  source  codes: 


UNCLASSIFIED 


37 


UNCLASSIFIED 

DSTO-TR-2931 

$ { WM_PRO JECT_USER_DIR } / 1 ib 

It  is  considered  a  good  practice  to  keep  any  third-party  code  separates  from  the  standard 
OpenFOAM  library.  Linking  the  VBM  library  to  the  standard  OpenFOAM  library  will  be 
done  during  compilation.  The  code  compilation  must  be  done  from  inside  the 
rotorDiskSource  directory.  The  first  step  of  the  compilation  involves  cleaning  the 
directory  from  any  previous  compilation  artefacts,  such  as  any  "  .  o"  or  "  .  dep"  files.  This 
can  be  done  as  follows: 

$  cd  ${wiyi_PROJECT_USER_DIR}/lib/rotorDiskSource 
$  rmdepall;  wclean 

3.5.2  Linking  the  VBM  Library  to  the  Standard  OpenFOAM  Libraries 

By  default,  the  compiler  links  to  shared  object  library  files  in  the  following  directory 
paths,  which  are  specified  with  the  -L  option  in  the  wmake: 

1.  The  $  {  F0AM_LIBBIN}  path; 

2.  Platform  dependent  paths  set  in  files  in  the 

$  { Wiyi_DIR}  / rules/ $  {wiyi_ARCH}  directory,  e.g .  /usr/Xll/lib  and 
$ { MPI CH_ARCH_PATH } / 1 ib; 

3.  Other  directories  specified  in  the  Make/ options  file. 

It  is  considered  standard  practice  for  any  third-party  object  files  or  executables  be  placed 
in  the  $  {  F0AM_USER_LIBBIN},  which  is  separate  from  the  standard  OpenFOAM 
installation  path.  The  ${foam_USER_LIBBIN}  is  a  standard  OpenFOAM  environment 
variable  set  during  installation.  However,  the  user  must  check  if  $  {foam_USER_LIBBIN} 
is  valid  on  their  OpenFOAM  installation.  This  can  be  done  using  the  standard  utility 
f oamlnstallationTest. 

The  library  files  to  be  linked  must  be  specified  using  the  - 1  option  and  removing  the  lib 
prefix  and  "  .  so"  extension  from  the  library  file  name,  e.g. 
libbasicThermophysicalModels  .  so  is  included  with  the  flag 
-IbasicThermophysicalModels. 

By  default,  wmake  loads  the  following  libraries  for  any  third-party  code  compilation: 

1.  The  libOpenFOAM .  so  library  from  the  ${  F0AM_LIBBIN}  directory; 

2.  Platform  dependent  libraries  specified  in  set  in  files  in  the 

$  { WM_DIR} /rules/$  { WM_ARCH}  ,  e.g.  /usr/Xll/lib/libm.  so  and 
${LAM_ARCH_PATH}/lib/liblam. so; 

3.  Other  libraries  specified  in  the  Make/options  file.  The  following  standard 
OpenFOAM  libraries  must  also  be  linked  during  compilation  of  the 
rotorDiskSource: 
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a.  -ImeshTools 

b.  -If initeVolume 


All  of  the  above  steps  can  be  accounted  for  by  creating  a  "Make"  directory  in  the 
rotorDiskSource  root  directory.  The  Make  directory  will  contain  two  new  files,  i.e. 
options  and  files.  The  Make/options  file  contains  the  full  directory  paths,  links  to 
the  standard  libraries,  and  the  new  library  name.  The  Make/ files  file  contains  the  list  of 
source  code  to  be  compiled.  The  content  of  the  Make/options  and  Make/files  files 
needed  to  compile  the  rotorDiskSource  library  are  shown  in  Figure  3.15  and  Figure 
3.16  respectively.  Note  that  from  this  example,  the  VBM  is  to  be  compiled  to  a  library 
named  "librotorDiskSource". 


EXE_INC  =  \ 

-DFULL_DEBUG  -g  -00  \ 
-l$CLlB_SRCVf>'eshToo1s/1nlnc1ude  \ 
-I  $  (LI  B_SRC  Vf  i  ni  t  evol  ume/1  nl  ncl  ude 

LIB_LIBS  =  \ 

-ImeshTools  \ 

-IfiniteVolume 


Figure  3.15:  Content  of  the  "Make/options"  needed  to  compile  rotorDiskSource 


r ot or Disk sour ce.c 
bl adeModel /bl adeModel . c 
prof i 1 eModel /prof i 1 eModel . c 
prof i 1 eModel /prof i 1 eModel Li sT . C 
prof i 1 eModel /I ookup/1 ookuppr of i 1 e. c 
pr of i 1 eModel /s eries/seriesPr of ile.c 
trimModel/trimModel/trimModel .c 
trimModel/trimModel/trimModel New.  c 
trimModel/f i xed/f i xedTrim.c 
t rimModel/tar get Force/tar get For ceTr im.  c 

LiB=$(FOAM_usER_LiBBiN)/librotorDisksource 


Figure  3.16:  Content  of  the  "Make/files"  needed  to  compile  rotorDiskSource 


3.5.3  Compiling  the  VBM  Library  (librotorDiskSource  .  so) 

Finally  the  code  can  be  compiled  by  running  the  following  command  from  the 
rotorDiskSource  root  directory: 

$  wmake  libso 

The  libso  option  is  a  flag  for  the  make  script  to  compile  the  librotorDiskSource  as  a 
dynamically  linked  library  instead  of  a  static  library  or  an  executable.  This  means  that  the 
library  is  not  loaded  by  the  solver,  unless  a  "rotorDiskSource"  object  is  instantiated  by 
the  "basicSource"  object.  Compiling  third-party  library  into  a  dynamically  linked 
library  in  OpenFOAM  is  also  considered  to  be  a  standard  practice.  Following  a  successful 
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compilation,  a  librotorDiskSource .  so  binary  file  should  be  available  at 
${foam_user_libbin}  path. 

3.6  Updating  the  VBM  Code  for  Compatibility  with  Future  OpenFOAM 
Version 

All  classes  included  in  the  VBM  library  developed  in  this  report  are  only  dependant  on  the 
structure  of  the  basicSource  class.  Therefore,  any  changes  in  the  OpenFOAM  solver(s) 
or  other  standard  OpenFOAM  libraries  in  the  future  versions  should  not  be  detrimental  to 
the  VBM  library.  However,  this  library  must  be  re-compiled  with  every  new  OpenFOAM 
release  prior  to  its  use.  The  procedure  for  compiling  the  code  is  described  in  Section  3.5. 
Furthermore,  any  necessary  solver  modifications  as  described  in  Section  3.3.3  will  also  be 
required. 

Changes  made  to  the  structure  of  the  basicSource  class  in  future  OpenFOAM  versions 
may  cause  compilation  of  the  VBM  library  code  to  fail.  However,  should  this  occur,  it  is 
expected  that  the  changes  required  to  the  VBM  codes  will  be  minimal,  and  are  expected  to 
only  be  made  to  the  constructor  of  the  rotorDiskSource  class.  While  it  is  almost 
impossible  to  predict  what  changes  may  occur  in  the  future  OpenFOAM  versions,  the 
following  steps  may  serve  as  a  starting  point  to  identify  the  changes  required  to  the  VBM 
code  should  it  fail  to  compile  with  a  future  OpenFOAM  version: 

1.  Check  that  the  library  names  included  in  the  Make /opt  ions  file  are  still  relevant. 
These  dependency  libraries  are  the  standard  OpenFOAM  libraries  that  contain 
low-Ievel  classes  that  are  not  likely  to  change  in  future  release.  These  libraries  are: 

a.  ImeshTools.  The  VBM  libraries  need  the  ImeshTools  for  getting  access 
to  mesh  information,  such  as  cellZone  and  faceZone,  cell  addressing, 
etc. 

b.  If  initeVolume.  The  VBM  libraries  need  the  If  initeVolume  for  getting 
access  to  FVM  related  information  in  the  mesh,  such  as  the  cell-centres,  cell- 
face  flux  field,  templated  data  type  and  operation  (volVectorField, 
coordinateSystems),  etc. 

2.  Check  that  the  names  and  constructors  of  the  basicSource  class's  virtual 
functions  implemented  in  the  rotorDiskSource  class  are  still  relevant.  These 
virtual  functions  are: 

a.  virtual  void  addSup  (  fvMatrix<vector>&;  eqn, 

const  label  fieldl  ) ; 

b.  virtual  void  writeData  (  OstreamSc)  const; 

c.  virtual  bool  read  (  const  dictionarySc  diet  )  ; 

3.  The  names  and  constructors  of  the  virtual  functions  listed  in  point  2  above  can  be 
checked  at  the  following  path: 
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$  { FOAiyi_SRC}  / f  initeVolume/ cfdTools /general/ f  ieldSources/basicS 
ource/basicSource 

The  implementation  of  these  virtual  functions  in  the  rotorDiskSource  class  can  be 
found  in  both  rotorDiskSource  .  H  and  rotorDiskSource  .  C.  The  names  and 
constructors  of  these  functions  in  the  rotorDiskSource  must  match  those  in  the 
basicSource  class. 
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4.  Case  Setup  in  OpenFOAM  using  the  rotorDiskSource 

Library 


4.1  Case  Setup 

This  section  provides  an  overview  of  a  typical  case  setup  in  OpenFOAM.  Unlike  many 
other  commercial  CFD  packages,  such  as  ANSYS,  the  standard  OpenFOAM  distribution 
does  not  have  a  Graphical  User  Interface  (GUI)  that  may  aid  the  user  in  preparing  a  case. 

Case  preparation  in  OpenFOAM  typically  involves  the  manual  preparation  of  all  the 
required  input  and  mesh  files.  These  files  must  adhere  to  a  specific  format  and  use  specific 
keywords  as  given  in  the  Chapter  4  of  the  OpenFOAM  User  Guide  (Reference  13). 
Furthermore,  the  required  files  and  formats  vary  significantly  depending  on  the 
OpenFOAM  solvers  and  Boundary  Conditions  to  be  used.  Therefore,  to  limit  the  scope  of 
this  report,  only  the  case  set  up  relevant  to  running  a  compressible  RANS  simulation  using 
the  rotorDiskSource  will  be  discussed. 

4.1.1  File  Structure 

An  OpenFOAM  case  is  defined  using  a  series  of  standard  files  that  are  arranged  with  a 
specific  directory  structure  and  naming  convention.  This  standard  structure  of  files  and 
directories  is  shown  in  Figure  4.1.  Different  OpenFOAM  solvers  and  libraries  may  require 
additional  input  files  in  the  case  setup,  which  may  not  be  shown  in  Figure  4.1.  Basic 
descriptions  of  each  file  shown  in  Figure  4.1  are  given  in  Table  4.1. 

An  example  of  a  case  setup  using  the  VBM  with  a  steady  state  RANS  solver  is  provided  in 
Appendix  B. 

An  OpenFOAM  case  directory  can  be  placed  anywhere  in  the  hard-drive  space;  however, 
it  is  normally  located  at  a  standard  location  given  by  the  standard  environmental  variable, 
$  { FOAM_RUN } .  In  setting  up  a  new  case,  all  file  names  and  directory  names  as  shown  in 
Figure  4.1  must  be  preserved.  The  directory  name  of  the  case  root  directory  as  indicated  in 
Figure  4.1  may  be  changed  to  better  reflect  the  case  name.  All  cases  must  be  run  using  a 
shell  terminal  from  the  case  root  directory  location. 

It  is  important  to  note  that  the  input  format  for  each  of  the  files  described  in  Table  4.1 
follows  some  general  principles  of  C++  source  code  as  follows  (Reference  14): 

1.  Files  have  free  form,  with  no  particular  meaning  assigned  to  any  column  and  no 
need  to  indicate  continuation  across  lines. 

2.  Lines  have  no  particular  meaning  except  to  a  //  comment  delimiter  which  makes 
OpenFOAM  ignore  any  text  that  follows  it  until  the  end  of  line. 

3.  A  comment  over  multiple  lines  is  done  by  enclosing  the  text  between  /*  and 
*/  delimiters. 
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Figure  4.1:  OpenFOAM  minimal  case  directory  structure  required  for  running  a  RANS 
simulation  using  the  rotorDiskSource  library 
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Table  4.1:  Brief  description  of  the  files  in  a  standard  OpenFOAM  case 


Directory 

Name 

File  Name 

Description 

Chapter  in 
OpenFOAM 
User  Guide 
(Reference 
13) 

system 

ControlDict 

A  dictionary  fiie  where  run  controi  parameters  are 
set  inciuding  start/end  time,  time  step  and  parameters  for  data 
output.  This  fiie  is  continuousiy  monitored  for  change  during 
runTime. 

Chapter  4.3 

fvSchemes 

A  dictionary  fiie  where  discretisation  schemes  used  in  the 
soiution  are  specified.  This  fiie  is  continuousiy  monitored  for 
change  during  runTime. 

Chapter  4.4 

f vSolution 

A  dictionary  fiie  where  the  iinear  matrix  soivers,  toierances  and 
other  aigorithm  controis  are  specified  for  the  run.  This  fiie  is 
continuousiy  monitored  for  change  during  runTime. 

Chapter  4.5 

decomposeParDict 

A  dictionary  fiie  where  the  domain  decomposition  methods  and 
the  number  of  sub-domains  to  be  used  on  a  paraiiei  MPi  run 
are  specified.  This  fiie  is  oniy  read  when  the  decomposePar 
command  is  run  as  a  pre-processing  step. 

Chapter  3.4 

constant 

RASProperties 

A  dictionary  fiie  where  the  turbuience  modeiiing  technique  is 
specified,  i.e.  kEpsiion,  kOmegaSST,  etc. 

Chapter  7.2 

thermophysicalPrope 

rties 

A  dictionary  fiie  where  the  fluid  thermophysicai  modei  and 
properties  are  specified  (e.g.  constant  specific  heat  modei  with 
evaiuation  of  enthaipy). 

Chapter  7.1 

transport Properties 

A  dictionary  fiie  where  the  transport  modei  (e.g.  Newtonian, 
Bird-Carreau,  etc)  and  the  fluid  moiecuiar  viscosity  is  specified 

Chapter  7.1 

sourceProperties 

A  dictionary  fiie  where  aii  zones  with  source  term  modeis  are 
specified,  inciuding  the  rotorDisksource. 

N/A 

constant/ 

polyMesh 

boundary 

Automaticaiiy  generated  mesh  fiie  that  contains  a  iist  of  patches 
(or  domain  boundaries),  containing  a  dictionary  entry  for  each 
patch,  deciared  using  the  patch  name,  e.g.  waii  or  iniet  patch. 

The  patch  name  can  be  updated  manuaiiy  by  the  user  by 
modifying  entries  in  this  fiie. 

Chapter 

5.2.1 

faces 

Automaticaiiy  generated  mesh  fiie  that  contains  a  iist  of  faces, 
each  face  being  a  iist  of  indices  to  vertices  in  the  points  iist, 
where  the  first  entry  in  the  iist  represents  face  0,  etc. 

Chapter  5.1 

neighbour 

The  polyMesh  description  is  based  around  faces  and  as  such, 
internai  ceiis  connect  2  ceiis  and  boundary  faces  address  a  ceii 
and  a  boundary  patch. 

Each  face  is  therefore  assigned  an  ‘owner’  ceii  and  ‘neighbour’ 
ceii  so  that  the  connectivity  across  a  given  face  can  simpiy  be 
described  by  the  owner  and  neighbour  ceii  iabeis.  This  fiie  is 
automaticaiiy  generated  during  mesh  conversion. 

Chapter  5.1 

owner 

See  description  for  neighbour  fiie  above. 

Chapter  5.1 

Table  continues  over  page  . . . 
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Table  continued  ... 


Directory 

Name 

File  Name 

Description 

Chapter  in 
OpenFOAM 
User  Guide 
(Reference 
13) 

points 

Automatically  generated  mesh  file  that  contains  a  list  of  points 
in  the  mesh,  defined  by  a  vector  in  units  of  metres  (m).  The 
points  are  compiled  into  a  list  and  each  point  is  referred  to  by  a 
label,  which  represents  its  position  in  the  list,  starting  from  zero. 

Chapter  5.1 

0 

p,  U,  T,  mut, 
alphat,  epsilon, 
omega,  R,  k 

A  Boundary  Condition  (BC)  must  be  specified  for  every  patches 
that  exist  in  the  constant/polyMesh/boundary  file.  In 
OpenFOAM,  each  flow  variables  that  are  solved  must  have  a 

BC  specified  against  each  patch.  This  means,  the  0  directory 
must  have  p  and  U  files  as  a  minimum  when  solving  a  laminar 
flow.  When  solving  a  turbulent  flow  using  RANS  "mut",  epsilon 
or  omega  and  k  must  exist.  When  solving  a  compressible  flow, 

T  and  alphat  must  exist. 

Chapter 

5.2.2 

through 

Chapter 

5.2.4 

Each  file  must  also  contain  the  initial  field  solution,  whether 
specified  as  a  “uniform”  value,  or  as  a  list  of  non-uniform 
values. 

The  various  inputs  specified  in  the  files  listed  in  Table  4.1  contain  "token"  or  keywords. 
Such  method  of  specifying  inputs  is  called  "dictionary  entries".  A  dictionary  is  an  entity 
that  contains  data  entries  that  can  be  retrieved  by  the  I/O  by  means  of  keywords. 
Therefore,  these  files  are  commonly  referred  to  as  "dictionary  files"  in  OpenFOAM. 
Furthermore,  the  keyword  entries  follow  the  general  format: 

<keyword>  <dataEntryl>  ...  <dataEntryN>  ; 

<keyword>  <dataEntry>; 


As  described  in  Reference  13,  most  OpenFOAM  data  files  are  themselves  dictionaries 
containing  a  set  of  keyword  entries.  Dictionaries  provide  the  means  for  organising  entries 
into  logical  categories  and  can  be  specified  hierarchically  so  that  any  dictionary  can  itself 
contain  one  or  more  dictionary  entries.  The  format  for  a  dictionary  is  to  specify  the 
dictionary  name  followed  by  keyword  entries  enclosed  in  curly  braces  { }  as  follows: 

<dictionaryNames> 

{ 

<keyword>  <dataEntry> ; 

<keyword>  <dataEntryl>  <dataEntry2>  ...  <dataEntryN>  ; 

} 

4.1.2  Time  Directory  (Output) 

Before  solving  for  a  flow  case,  a  directory  named  "O"  must  exist  as  shown  in  Table  4.1. 
This  "O"  directory  is  the  first  time  directory,  named  after  the  "start  time".  Note  that  the 
solver  will  look  for  the  same  time  directory  number  which  matches  that  specified  by  the 
keyword  startTime  in  the  controlDict  file,  and  usually  equals  "0".  The  "0"  directory 
contains  the  initial  field  values  and  the  boundary  conditions  for  all  flow  variables  that  are 
going  to  be  solved.  A  typical  boundary  conditions  setup  that  can  be  used  for  running  both 
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incompressible  and  compressible  external  aerodynamic  flow  with  field  momentum 
sources  present  in  the  domain  will  be  discussed  later  in  Section  4.4. 


Results  are  written  out  in  the  manner  specified  by  the  keywords  writeControl  and 
writeinterval  in  the  controlDict  file.  Allowable  parameters  for  these  are  specified 
in  Table  4.2.  Results  are  written  out  into  a  time  directory  with  the  directory  name 
corresponding  to  the  current  iteration  count  or  the  flow  time  step. 


Table  4.2:  Specifying  writeData  control  in  the  controlDict  File 


Keyword 

AllowableValue 

Description 

stopAt 

endTime 

Stops  at  time  specified  by  the  endTime  keyword  entry. 

writeNow 

Stops  simulation  on  completion  of  current  time  step  and  writes  data. 

noWriteNow 

Stops  simulation  on  completion  of  current  time  step  and  does  not  write 
out  data. 

nextWrite 

Stops  simulation  on  completion  of  next  scheduled  write  time,  specified 
by  writeControl. 

deltaT 

[floatinq  point] 

Time  step  of  the  simulation.  If  steady,  it  can  be  specified  as  1  to  be  used 
as  the  iteration  counter. 

writeControl 

timeStep 

Controls  the  timing  of  write  output  to  file.  Writes  data  every  writeinterval 
time  steps. 

runTime 

Writes  data  every  writeinterval  seconds  of  simulated  time. 

adj  ustableRunTime 

Writes  data  every  writeinterval  seconds  of  simulated  time,  adjusting  the 
time  steps  to  coincide  with  the  writeinterval  if  necessary  —  used  in 
cases  with  automatic  time  step  adjustment  (based  on  Courant  Criteria). 

cpuTime 

Writes  data  every  writeinterval  seconds  of  CPU  time. 

clockTime 

Writes  data  out  every  writeinterval  seconds  of  real  time. 

writeinterval 

[floatinq  point] 

Scalar  used  in  conjunction  with  writeControl  described  above. 

purqeWrite 

[floatinq  point] 

Integer  representing  a  limit  on  the  number  of  time  directories  that  are 
stored  by  overwriting  time  directories  on  a  cyclic  basis.  Example  of  tO  = 

5s,  At  =  1s  and  purgeWrite  2; 

data  written  into  2  directories,  6  and  7,  before  returning  to  write  the  data 
at  8  s  in  6,  data  at  9  s  into  7,  etc. 

To  disable  the  time  directory  limit,  specify  purgeWrite  0;  For  steady-state 
solutions,  results  from  previous  iterations  can  be  continuously 
overwritten  by  specifying  purgeWrite  1; 

4.2  Specifying  the  rotorDiskSource  Properties  in  the 
sourceProperties  Dictionary  File 

4.2.1  Basic  Selection  Mechanism 

In  order  to  use  the  rotorDiskSource  library  in  a  simulation,  a  sourceProperties  file 
containing  the  parameters  required  by  the  rotorDiskSource  library  must  exist  in  the 
constant  directory  for  the  case  considered. 
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As  previously  discussed  in  Section  3.3.4,  an  abstract  class  (basicSource)  is  used  in  the 
solver.  The  implementation  of  this  basicSource  class  depends  on  the  "type"  entry  in 
the  case  sourceProperties'*  dictionary  file  as  shown  in  Figure  4.2.  This  selection 
mechanism  allows  user  to  specify  multiple  source  regions  in  the  computational  domains 
with  differing  implementations.  An  example  of  this  is  the  ability  to  specify  two  source 
regions  where  one  region  contains  the  VBM  model,  and  the  other  contains  a  heat  source. 
In  the  example  shown  in  Figure  4.2,  a  rotorDisk  object,  arbitrarily  named  "mainrotor", 
is  instantiated  in  the  domain  for  all  computational  cells  included  in  the  "  fluid - 
mainRotor"  cellZone^  When  a  rotorDisk  type  source  object  is  selected,  the  user 
must  then  define  all  parameters  inside  the  rotorDiskCoef  f  s  keyword  entry  as  required 
by  rotorDiskSource  class  as  described  in  Section  4.2.2  through  Section  4.2.4. 


Multiple  rotorDisk  regions  are  allowed,  provided  that  each  cellZone  representing  the 
rotor  disk  region  is  attached  to  only  one  object.  An  example  of  this  is  also  shown  in  Figure 
4.2,  where  a  second  rotorDisk,  named  "tailrotor"  object,  is  instantiated  in  the 
domain  on  all  cells  included  in  the  f  luid-tailRotor  cellZone.  There  is  no  limit  on 
the  number  of  rotorDisk  objects  that  can  be  instantiated  in  a  computational  domain. 


FoamFile 

{ 

version  2.0; 

format  ascii; 

class  dictionary; 

location  "constant  ; 

object  sourcesproperties; 

mainrotor 
{ 

type 
active 
timestart 
duration 
selectionMode 
cel Izone 

rotorDiskCoeffs 
{ 

} 

} 


tailrotor 
{ 

type 
active 
timestart 
duration 
selectionMode 
cellZone 

rotorDiskCoeffs 

{ 

} 

} 


Figure  4.2:  Source  term  model  selector  in  the  sourceProperties  file 


*  Note  that  sourceProperties  file  is  a  common  "dictionary"  file  that  is  read  by  many  different  source 
term  implementations  in  OpenFOAM. 

5  The  term  cellZone  in  OpenFOAM  refers  to  the  same  cell-zone  in  the  ANSYS  Fluent  terminology. 


rotorDisk; 

on; 

0.0; 

100000.0; 
cel  Izone; 
fluid-tail  Rotor; 


rotorDisk; 

on; 

0.0; 

100000.0; 

cellZone; 

fluid-mainRotor; 
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4.2.2  Specifying  Basic  rotorDiskSource  Coefficients 


All  keyword  entries  shown  in  Figure  4.3  must  be  specified  for  each  rotorDisk  object.  In 
an  incompressible  simulation,  the  fluid  density,  rho,  is  not  computed;  hence,  a  reference 
value  for  rho  must  be  specified  using  the  keyword  rhoRef . 


rotorDlskCoetts 

{ 

f i el dNames 

(u); 

rhoName 

rho; 

rhoRef 

1.225; 

// 

geometryMode 

specified; 

// 

origin 

CO. 456998  0.0  0.137100); 

// 

axi  s 

CO  0  1); 

// 

refDirection 

Cl  0  0); 

geometryMode 

auto; 

Cl  0  0); 

refDirection 

pointAbove 

CO  0  1); 

rpm 

2100; 

nBlades 

2; 

i nl etFl owType 

local ; 

tipEffect 

0.96;  //  1.0; 

f 1 apcoeff s 

betaO 

0; 

bet  al 

1.  94; 

beta2 

2.03; 

} 

Figure  4.3:  Basic  rotorDiskCoejfs  parameters  in  the  sourceProperties  file 


The  keyword  geometryMode  indicates  the  method  that  rotorDiskSource  will  use  to 
determine  the  rotor  disk  origin.  When  the  "auto"  mode  is  selected,  the  code  will  calculate 
the  origin  of  the  rotor  disk  cell  Zone  using  a  cell  volume-weighting  method.  The  origin 
vector  is  mathematically  described  by  Equation  4.1: 


O  disk 

where  is  the  cell  volume,  and  C, 

The  rotor  disk  axis  will  also  be  calculated  using  the  orientation  of  the  face  normal  vectors 
on  each  cell  included  in  the  rotor  disk  cell  Zone.  The  rotor  disk  axis  vector  is  determined 
by  summing  the  face  area  vector  on  every  cell  included  in  the  rotor  disk  cell  Zone  that 
are  closely  aligned  with  the  pointAbove  vector.  The  axis  is  expressed  as  a  unit  vector, 
which  is  mathematically  shown  in  Equation  4.2: 


celll _ 


[Equation  4.1] 


celll 


is  the  cell-centre  position  vector. 
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_  IL 

N  disk  =  [Equation  4.2] 

celll 

where  S'y  is  the  surface  area  vector  of  each  cell  face  that  is  normal  to  the  disk  surface. 

The  user  must  always  check  for  the  correctness  of  the  calculated  rotor  disk  origin  and  axis 
during  runtime  by  looking  at  the  runtime  log  printed  to  the  screen. 

Eor  the  main  rotor,  the  refDirection  and  pointAbove  are  vectors  in  the  direction  of 
the  positive  X-axis  and  positive  Z-axis  in  the  mesh  respectively.  It  is  good  practice  to  create 
the  helicopter  and  rotor  disk  model  in  the  mesh  with  the  helicopter  nose  pointing  in  the 
negative  X-direction  direction,  and  the  lift  vector  pointing  close  to  the  positive  Z-direction. 
These  refDirection  and  pointAbove  vectors  are  used  in  the  code  to  construct  the 
Cartesian  to  cyclindrical  coordinate  transformation  matrix,  and  do  not  have  to  precisely 
reflect  the  orientation  of  the  freestream  flow  and  lift  vector. 

The  keyword  rpm  is  the  rotor  blade  speed  in  revolutions  per  minute  (RPM).  This  quantity 
needs  to  be  an  integer,  and  is  specified  as  positive  when  the  rotor  blade  is  rotating  counter¬ 
clockwise  when  viewed  from  above  (i.e.  a  view  in  the  negative-lift  direction). 

The  keyword  nB lades  is  the  number  of  rotor  blades  in  the  rotor. 

The  keyword  inletFlowType  specifies  the  type  of  inlet  flow  into  the  rotorDisk  region. 
When  this  is  specified  as  "local",  the  code  will  use  the  local  velocity  value  in  the 
rotorDisk  region.  Otherwise,  a  user-defined  velocity  profile  on  the  rotorDisk  can  be 
specified  by  setting  this  parameter  value  to  either  "fixed"  or  "surf aceNormal".  An 
example  of  the  latter  settings  is  shown  in  Eigure  4.4. 


Figure  4.4:  Methods  of  specifying  inlet  flow  into  the  rotor  disk  in  the  sourceProperties  file 

The  keyword  tipEf feet  specifies  the  blade  radius  position  over  which  the  momentum 
source  in  the  disk  will  be  reduced  to  zero.  This  parameter  is  specified  as  a  non- 
dimensionalised  radial  position  on  the  disk  normalised  by  the  rotor  radius,  i.e.  a  value  of  1 
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corresponds  to  the  tip  of  the  rotor  disk  region,  while  a  value  of  0.96  represents  a  radial 
position  at  96  per  cent  of  the  disk  radius  relative  to  the  disk  origin. 

The  keyword  f  lapCoeffs  specifies  the  blade  flapping  constants,  given  in 

Equation  2.5  at  Section  2.2.3.  These  constants  represent  the  coning,  cosine  and  sine 
flapping  angles  respectively;  and  thus  have  a  unit  of  degrees. 

4.2.3  Specifying  Blade  Trim  Parameters 

A  "trim"  model  must  always  be  specified  for  each  rotor  disk  region  in  the 
sourceProperties  file.  An  untrimmed  rotor  is  deemed  to  have  a  "f  ixedTrim"  model 
as  shown  in  Eigure  4.5.  If  a  fixedTrim  model  is  selected,  a  set  of  trim  coefficients  need  to  be 
specified  in  accordance  to  the  definition  shown  in  Equation  2.3  at  Section  2.2.2.  These  trim 
coefficients,  denoted  as  a^,A,B\r\  the  sourceProperties  file,  correspond  to  the  blade 
collective  pitch  angle,  and  the  cosine  and  sine  cyclic  pitch  angles  respectively.  These  angles 
should  always  be  specified  in  their  first-quadrant  values  irrespective  of  the  direction  of 
rotation.  Eor  example,  a  blade  collective  pitch,  ,  of  positive  10  represents  a  blade  pitch 
angle  of  10  degrees  regardless  whether  the  blade  is  rotating  in  the  counter-clockwise  or 
clockwise  direction.  Note  that  changing  these  values  will  not  alter  the  rotor  disk 
orientation  in  the  mesh. 


triitiHodel 

fixedTrim;  //  targetForceTr im;  //  fixedTrim; 

f  ixedTr  iitiCoef  f  s 

{ 

alphaC 

10; 

A 

0; 

B 

0; 

> 

targetForceTr  irnCoef  fs 

{ 

target 

< 

f Thrust 

72.8; 

mRoll 

0; 

mPitch 

0; 

> 

pitchAngles 

{ 

alphaCIni 

5; 

AIni 

0; 

BIni 

0; 

> 

calcFrequency 

5; 

dTheta 

0.1; 

relax 

1; 

> 

Figure  4.5:  Cyclic  and  collective  pitch  trim  parameters  in  the  sourceProperties  file 
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The  blade  trimming  calculation  can  be  "activated"  by  specifying  "targetForceTrim"  as 
the  trimModel.  When  blade  bimming  is  carried  out  in  the  simulation,  the 
f  ixedTrimCoef  f  s  entries  will  be  ignored  by  the  code.  Instead,  the  user  must  specify  the 
targetForceTrimCoef  f  s  entries  as  shown  in  Figure  4.5. 

As  previously  discussed  in  Section  2.3.7  and  Section  3.4.3,  the  trimming  is  done  by 
perturbing  the  blade  collective  and  cyclic  pitch  angles  at  a  frozen  flow  state  (at  each  flow 
solver  iteration)  to  find  a  combination  of  blade  collective  and  cyclic  pitch  angles  that  will 
return  the  global  thrust  and  moments  on  the  rotor  disk  that  match  the  user-specified  target 
rotor  thrust  and  moments.  The  keyword  f Thrust  shown  in  Figure  4.5  specifies  the 
desired  total  thrust  acting  on  the  disk  in  Newtons.  The  keywords  mRoll  and  mPitch 
specify  the  desired  total  rolling  and  pitching  moments  acting  on  the  disk  in 
Newton-meters. 

Usually  the  rotor  total  thrust  and  moments  for  a  particular  flight  condition  are  specified  by 
the  Original  Equipment  Manufacturer  (OEM)  as  non-dimensionalised  quantities  of 
coefficients  of  thrust  and  coefficients  of  moments  as  given  by  Equations  2.37  through  2.39 
in  Section  2.3.7. 

The  keyword  alphaCIni,  AIni  and  BIni  are  the  initial  guesses  of  the  blade  collective 
pitch  angle  and  cyclic  pitch  coefficients  (refer  to  Equation  2.36  in  Section  2.3.7). 

The  keyword  calcFrequency  specifies  the  interval  (in  flow  iterations)  in-between 
trimming  routines.  The  keyword  dTheta  specifies  the  angles  by  which  the  local  blade 
AOA  needs  to  be  perturbed  during  trimming  (the  default  value  is  0.05  degree). 

The  URF  for  the  newly  calculated  AOA  during  trimming  is  specified  by  the  keyword 
relax  as  shown  in  Figure  4.5.  Note  that  for  stability  reasons,  this  factor  should  be  kept  at 
one  unless  the  trimming  routine  is  unable  to  find  a  trimmed  solution  within  its  iteration 
limits.  This  iteration  limit  in  the  trimming  loop  is  "hard-coded"  to  be  50  iterations,  in  the 
source  file  "targetForceTrim.  C".  However,  the  user  may  override  this  setting  by 
adding  a  keyword  niter  and  specifying  an  integer  value  in  the  line  following  the  relax 
keyword. 


4.2.4  Specifying  Blade  Geometry  and  Section  Profile 

A  blade  geometry  and  blade  section  profile  must  be  specified  for  each  of  the  rotor  objects 
created  in  the  "sourceProperties"  file.  An  example  of  a  setup  for  a  linearly  tapering 
blade  with  a  NACA0015  section  is  shown  in  Figure  4.6.  In  this  example,  the  blade  has  zero 
twist  along  its  radius,  and  is  linearly  tapered  from  a  chord  length  of  0.086  m  at  r  =  0.45  m, 
to  a  chord  length  of  0.075  m  at  its  tip.  The  blade  radius  is  shown  to  be  0.8  m.  Note  that 
currently  only  a  linear  taper  is  supported  by  the  code. 
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blade 

{  1 1  radius  traist  chord 

data 
( 


(NACA0015 

( 

0 

0.086)  ) 

(NACAD015 

[0.45 

0 

0.086)  ) 

(NACA0015 

(0.45 

0 

0.086)  ) 

(NACAQ015 

[0.8 

0 

0.075)  ) 

) ; 

> 


Figure  4.6:  Blade  geometry  and  profile  specification  in  the  sourceProperties  file 

The  "NACA0015"  shown  in  Figure  4.6  can  be  arbitrarily  named.  However,  this  naming 
must  correspond  to  the  "profile"  entry  setup  as  described  later  in  Section  4.2.5. 

The  setup  shown  also  allows  the  blade  to  be  defined  in  multiple  segments,  where  in  each 
segment  an  independent  section  profile,  and  a  linear  variation  of  twist  angle  and  taper,  can 
be  defined.  Each  blade  segment  can  be  defined  using  a  pair  of  entries  specifying  the 
segment  start  and  end  radii,  blade  twist  angle,  and  chord. 

4.2.5  Specifying  Section  Profile  Lift  and  Drag  Curves 

Following  the  blade  geometry  and  section  profile  specification,  the  lift  and  drag  curves  for 
a  range  of  AOA  must  be  specified  for  each  blade  segment.  Using  the  example  shown  in 
Figure  4.6,  NACA0015  lift  and  drag  curves  as  a  function  of  AOA  must  be  specified.  This  is 
shown  in  Figure  4.7. 

As  shown  in  Figure  4.7,  there  are  two  ways  of  specifying  the  lift  and  drag  curves  for  the 
selected  NACA0015  airfoil,  i.e.  using  a  "series"  mode  or  a  "lookup"  mode.  In  the 
"series"  mode,  the  Cl  curve  is  represented  using  a  sine  series,  while  the  Cd  curve  is 
represented  using  a  cosine  series  as  shown  by  the  equations  in  the  same  Figure.  The 
numbers  shown  in  the  sourceProperties  file  (Figure  4.7)  are  the  z*  coefficient  {Ci„\ 
and  ).  for  the  respective  series  equations.  These  coefficients  have  been  generated  by 
fitting  the  Cl  and  Cd  versus  AOA  using  the  sine  or  cosine  series  respectively.  The  fitted 
raw  data  for  the  Cl  and  Cd  must  cover  AOA  ranging  from  -  n  to  +7i. 

In  the  "lookup"  mode,  the  lift  and  drag  curves  are  described  using  point  data  as  shown  in 
Figure  4.7.  During  computation,  the  values  for  Cl  and  Cd  for  any  AOA  are  linearly 
interpolated  from  the  point  data  specified  in  the  sourceProperties  file.  The  data  must 
cover  AOA  ranging  from  -n  to  +n. 
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profiles 

{ 


NACA0015 

{ 

type  series; 

CdCoef fs 

t 


i=l 


1.09853905176285  -0 . 025‘J111379715975  -1.01464921175951 
0.000297893132963066  -0.0805674417410576  0.0003478832627729604 
0.0183641071501486  -0.00187212740610965  0.00738154463596278 
-0.0271646860125189  -0.0201573706491855  0.00310230620458444 
-0.00738192972395497  0.0172792907248443  0.0141795478822924 
0.0228307118297743 


ClCoeffs 


«  ,  s 


1=1 


0.0  0.122067939602577  1.12197137626962  -0.0198082665751631 
0.091486923514929  0.0146427968325049  0.0511391044755384 
0.0158813079932265  0.105584091108421  0.00367478325400266 
0.127744823649244  -0.00715619228634737  0.100691143636163 
-0.0108010398622889  0.0564061685913662  -0.00846889180607761 


> 


)  ; 


NACA0015 

< 


type 

data 

lookup; 

t  // 

alpha 

Cd 

Cl 

t 

-180 

0.02 

0 

t 

-90 

2.02 

-0.06 

t 

-30 

0.56 

-0.98 

t 

0 

0.01 

0 

t 

30 

0.56 

0.98 

t 

90 

2.02 

0.06 

t 

120 

1.65 

-0.75 

t 

180 

0.02 

0 

); 

> 

> 


Figure  4.7:  Airfoil  section  lift  and  drag  curves  specification  in  the  sourceProperties  file 


4.3  Mesh  Requirement 

As  previously  discussed  in  Section  2.3.6,  the  rotorDiskSource  library  introduces  a 
momentum  source  on  each  cell  included  in  a  separate  cell  zone  or  fluid  region.  This 
separate  rotor  cell  zone  must  be  made  up  of  a  collection  of  one-cell  thick  hexahedral  cells 
forming  a  cylindrical  disk.  The  thickness  of  the  cells  must  be  chosen  so  as  to  give  the  best 
possible  aspect  ratio  (close  to  one)  to  the  hexahedral  cells. 

The  rotor  disk  may  also  have  an  inner  central  hole  to  allow  for  the  rotor  shaft  with  a  no- 
aerofoil  region  (also  called  "blade  root  cutout").  The  addition  of  the  central  hole  in  the 
middle  of  the  rotor  disk  is  also  considered  a  good  practice  for  avoiding  mesh  singularity  at 
the  centre  of  the  disk. 
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An  example  of  this  setup  is  shown  in  Figure  4.8.  Note  that  due  to  the  specific 
implementation  of  the  momentum  source  terms  (discussed  in  Section  2.3.6),  only 
hexahedral  cells  are  allowed  in  the  rotor  disk  region. 


Figure  4.8:  An  example  of  rotor  disk  mesh  using  structured  hexahedral  cells 

Although  the  rotor  disk  region  can  only  be  constructed  from  hexahedral  cells,  other  parts 
of  the  domain  may  be  constructed  using  any  other  type  of  cells,  i.e.  tetrahedral  or 
polyhedral.  However,  if  tetrahedral  cells  are  used  in  the  domain,  a  series  of  pyramid 
shaped  cells  need  to  be  attached  on  the  rotor  disk  surfaces  in  order  to  smoothly  blend  the 
hexahedral  cells  in  the  rotor  disk  region  to  the  tetrahedral  cells  in  the  domain.  An  example 
of  this  is  shown  in  Figure  4.9. 
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NOTE:  Pyramidal  cells  attached  to  the  rotor 
disk  top  surface  have  been  omitted  from  view 
for  clarity 


Figure  4.9:  An  example  of  pyramid  cells  attachment  on  the  rotor  disk  mesh  in  a  fully  unstructured 
tetrahedral  cell  domain  -  generated  using  ANSYS  TGrid 

OpenFOAM  does  not  include  robust  geometry  manipulation  and  meshing  tools.  Hence,  as 
a  standard  practice,  the  geometry  and  mesh  need  to  be  generated  using  third  party 
software  packages.  A  range  of  third  party  meshing  software  packages  that  have  been 
tested  to  be  compatible  with  OpenFOAM  are  shown  in  Figure  4.10. 

From  the  range  of  third-party  geometry  modeller  and  meshing  software  shown  in  Figure 
4.10,  Pointwise  and  ANSYS  Gambit/TGrid  have  been  successfully  used  for  creating  the 
geometry  and  meshes  used  in  this  project.  Pointwise  has  the  ability  to  natively  export  the 
created  mesh  into  an  OpenFOAM  format.  However,  meshes  created  using  ANSYS  Gambit 
and  TGrid  need  to  be  first  exported  into  ANSYS  Fluent  format.  The  resulting  ANSYS 
Fluent  mesh  can  then  be  converted  into  an  OpenFOAM  mesh  using  the 
f  luentSDMeshToFoam  utility  which  is  included  in  the  standard  OpenFOAM 
distribution. 
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Geometry  Meshing 

BlockMesh 


CAD  Tools 
STL 

SnappyHexMesh 

Gridgen/Pointwise 

enGrid 

Salome 

ANSYS  Gambit/TGrid 

ANSYS  CFX/ICEM 

Others 

Others 

Solver 


OpenFOAM 


Postprocessing 


utilities  Lib 


Gnupiot 


Octave 


Para  view 


Tecpiot 


Fieldview 


Ensight 


Others 


OpenFOAM  ^  H  Commercial  Package 

Figure  4.10:  OpenFOAM  user  environment 

The  ANSYS  Gambit  and  ANSYS  TGrid  software  are  widely  available  within  DSTO. 
Therefore,  only  the  method  of  generating  the  rotor  disk  mesh  using  ANSYS  Gambit  and 
TGrid  will  be  discussed  in  this  report. 

4.3.1  Generating  Rotor  Disk  Mesh  Using  ANSYS  Gambit  and  ANSYS  TGrid  for 
Use  in  OpenFOAM 

Reference  1  provides  a  detailed  discussion  on  the  development  of  the  VBM  in  the  ANSYS 
Fluent  environment.  A  detailed  procedure  on  how  to  create  the  rotor  disk  mesh  in  a  CFD 
model  using  ANSYS  Gambit  and  TGrid  is  also  included  in  Section  3.2  of  Reference  1. 
Therefore,  this  procedure  will  not  be  repeated  in  this  report.  However,  during  review  of 
Reference  1,  it  was  found  that  the  use  of  prismatic  cells  to  construct  the  rotor  disk  is  not 
appropriate  for  the  VBM  method  (refer  to  Section  2.3.6).  Therefore,  it  is  recommended  that 
the  rotor  disk  region  is  constructed  in  ANSYS  Gambit  (or  any  other  preferred  geometry 
modelling  software)  using  structured  hexahedral  cells  only.  Pyramidal  cell  caps  can  then 
be  placed  on  the  rotor  disk  surfaces  to  transition  the  hexahedral  cells  to  the  tetrahedral 
cells  for  meshing  the  fluid  domain  as  per  the  guidance  given  in  Reference  1. 

Following  the  procedure  given  at  Reference  1,  the  mesh  can  be  saved  as  a  Fluent  type 
mesh  file  format  (.msh)^.  Although  the  OpenFOAM  translation  routine, 
"f  luentBDMeshToFoam"  is  able  to  translate  the  .msh  file  into  OpenFOAM  format,  it  was 
found  that  the  same  routine  performs  better  with  ANSYS  Fluent  case  file  format  (.cas). 
Therefore,  it  is  considered  to  be  a  good  practice  to  load  the  ANSYS  Gambit/TGrid 
generated  mesh  into  ANSYS  Fluent,  and  then  save  the  mesh  into  a  "dummy"  case  file  (in 
.cas  format). 


6  IMPORTANT:  the  Fluent  case  file  will  need  to  be  written  in  ASCII  format  for  translation 
into  OpenFOAM  format. 
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Conversion  of  an  ANSYS  Fluent  case  into  an  OpenFOAM  format  requires  the  user  to  first 
set  up  a  standard  OpenFOAM  case  directory  structure  (previously  shown  in  Figure  3.7)  in 
the  intended  OpenFOAM  working  path.  For  the  purpose  of  importing  the  mesh  from  a 
Fluent  format  into  OpenFOAM,  the  "polyMesh"  directory  inside  the  case  directory 
structure  must  be  empty.  The  conversion  routine  will  subsequently  populate  this  directory 
to  contain  the  files  needed  to  define  the  mesh  in  OpenFOAM. 

Prior  to  the  mesh  conversion,  the  "dummy"  ANSYS  Fluent  case  file  needs  to  be  copied 
into  the  OpenFOAM  case  "root  directory".  This  is  the  top  level  location  in  the  case 
directory  structure.  Following  this,  the  mesh  conversion  can  be  started  by  issuing  the 
following  command  from  the  Bash  shell  terminal  from  the  case  root  directory  location: 

$  f luentBDMeshToFoam  -scale  <factor>  <f ilename . cas>  -writeZones 
-writeSets 

The  input  <f  actor>  is  the  mesh  geometric  scaling  factor  to  be  applied  during  conversion, 
e.g.  if  the  mesh  was  created  in  the  unit  of  mm,  the  entry  < f  actor >  should  be  replaced 
with  0.001.  The  input  <  filename  .  cas>  should  be  replaced  with  the  ANSYS  Fluent  case 
filename,  including  the  full  or  relative  path  to  the  ANSYS  Fluent  case  file. 

Following  a  successful  mesh  conversion,  the  polyMesh  directory  will  be  populated  with 
the  files  as  shown  in  Figure  4.11.  Details  on  the  mesh  topology  and  conventions  used  in 
OpenFOAM  are  available  from  Chapter  5  of  Reference  13. 


<case> 


L 


constant 


-  ...Properties 

polyMesh 


-  points 

-  cells 

-  faces 

-  boundary 


Figure  4.11:  polyMesh  directory  structure  in  an  OpenFOAM  case 


The  "points",  "cells",  and  "faces"  files  contain  a  long  list  of  numbers  which  are  used 
for  cell  and  face  addressing.  The  "boundary"  file  contains  the  patch  definition  in  the  mesh. 
It  is  important  to  note  that  the  patch  definitions  contained  in  the  "boundary"  file  are  not 
the  boundary  conditions  for  the  case.  The  boundary  conditions  need  to  be  set  up  in  the  "0" 
directory  in  the  case  directory.  Boundary  conditions  setup  will  be  discussed  in  Section  4.4. 

Prior  to  setting  up  the  boundary  conditions  for  the  case,  the  user  should  check  if  the 
separate  cellZone  or  region  that  the  rotor  disk  was  created  in  has  been  preserved 
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correctly  during  the  mesh  conversion.  The  simplest  way  to  check  this  is  to  make  sure  that 
the  "cellZone"  file  located  in  the  polyMesh  directory  has  at  least  two  separate 
cell  Zone  as  indicated  in  Figure  4.12. 


The  final  step  involved  in  the  process  of  preparing  an  OpenFOAM  mesh  from  an  ANSYS 
Fluent  mesh  is  to  reorder  the  mesh  addressing  in  the  domain  to  improve  the 
computational  performance  of  the  solvers.  The  reordering  procedure  involves  rearranging 
the  points,  faces  and  cells  addressing  to  improve  the  bandwidth  of  the  FV  Matrix,  once 
constructed,  during  runtime.  In  general,  the  faces  and  cells  are  reordered  so  that  the 
neighboring  cells  are  near  each  other  in  the  zone  and  in  memory.  Since  most  of  the 
computational  loops  are  over  faces  (e.g.  calculation  of  the  cell  face  flux),  it  is  best  to  place 
two  adjacent  cells  next  to  each  other  in  the  memory  addressing  slots. 

The  imported  mesh  can  be  reordered  by  issuing  the  following  command  from  the  case  root 
directory: 

$  renumberMesh  -overwrite 


/» - *_  C++  -* - *\ 


I  \\  /  F  ield  I  OpenFOAM:  The  Open  Source  CFD  Toolbox  | 

I  \\  /  O  peration  |  Version:  2.1.x  | 

I  \\  /  A  nd  I  ¥eb:  ¥¥w. OpenFOAM. or g  | 

I  \\/  M  anipulation  |  | 

- V 

FoamFile 

{ 

version  2.0; 

format  ascii; 

class  reglOobject; 

location  "constant/polyMesh"; 
object  cellZones; 

> 

//*****l***:t***ll***l***l»*******l****»// 


2 
( 

fluid-rot 
{ 

type  cellZone; 
cellLabels  List<label> 

6000  I 

( 

0 

1 

2 _ 


Total  cell  count  in  rotor  disk  region 


Total  number  of  cellZones  (or  regions)  in  the  mesh 

rotor  disk  region  name 

Figure  4.12:  polyMesh  directory  structure  in  an  OpenFOAM  case 


4.4  Setting  Up  the  Boundary  Conditions 

The  OpenFOAM  mesh  conversion  utility,  f  luentBDMeshToFoam,  will  attempt  to  capture 
the  ANSYS  Fluent  boundary  condition  definitions  as  much  as  possible.  However,  since 
there  is  no  dear,  direct  correspondence  between  the  OpenFOAM  and  ANSYS  Fluent 
boundary  conditions,  the  user  must  make  manual  adjustments  in  the  OpenFOAM  case 


58 


UNCLASSIFIED 


UNCLASSIFIED 

DSTO-TR-2931 

prior  to  running  the  case.  The  following  sub-sections  will  provide  a  high-level  overview  of 
boundary  conditions  that  are  readily  available  in  OpenFOAM  for  typical  cases  involving 
the  use  of  VBM. 

4.4.1  Overview  of  Boundary  Patches  and  Boundary  Conditions  in  OpenFOAM 

Following  a  successful  mesh  conversion  from  an  ANSYS  Fluent  mesh  format  to  an 
OpenFOAM  format,  a  "boundary"  file  will  be  automatically  created  by 
f  luentBDMeshToFoam  and  placed  inside  the  polyMesh  directory.  The  "boundary"  file 
contains  the  type  associated  with  each  imported  domain  boundary  surface  included  in  the 
Fluent  mesh  that  are  readily  recognisable  by  the  f  luentBDMeshToFoam.  These  boundary 
types  include:  patch,  wall,  symmetry  plane,  and  cyclic  plane.  If  a  2D  mesh  is  imported,  then  a 
pair  of  empty  plane  or  wedge  plane  will  be  created  to  simulate  the  symmetry  plane  or  the  cyclic 
plane  for  the  2D  planar  and  2D  axisymmetric  case  respectively.  Note  that  a  2D  mesh  is  not 
suitable  for  using  the  rotorDiskSource  library. 

In  OpenFOAM,  a  boundary  surface  is  generally  broken  up  into  a  set  of  patches.  One  patch 
may  include  one  or  more  enclosed  areas  of  the  boundary  surface  which  do  not  necessarily 
need  to  be  physically  connected  (Reference  13).  The  type  definition  included  in  the 
boundary  file  is  therefore  only  associated  with  the  mesh  hierarchy.  In  addition  to  the  type 
definition  included  in  the  boundary  file,  a  numerical  boundary  condition  must  also  be 
defined  for  each  boundary  surface. 

In  summary,  there  are  two  attributes  associated  with  a  "patch”  that  are  described  below  in 
their  natural  hierarchy.  Figure  4.13  also  shows  the  names  of  different  patch  types 
introduced  at  each  level  of  the  hierarchy. 

•  Base  type.  The  type  of  patch  described  purely  in  terms  of  geometry  or  a  data 
'communication  link'. 

•  Numerical  type.  The  boundary  conditions  describing  the  treatment  of  field 
variables  on  a  particular  base  type  patch.  These  are  split  into  two  categories: 

a.  Primitive  type.  The  base  numerical  patch  condition  assigned  to  a  field 
variable  on  the  patch.  Some  examples  of  these  are:  the  Dirichlet  Condition 
(fixdValue),  zero  Neumann  Condition  (zeroGradient),  etc. 

b.  Derived  type.  A  complex  patch  condition,  derived  from  the  primitive  type, 
assigned  to  a  field  variable  on  the  patch.  Some  examples  of  these  are:  the 
totalPressure,  inletOutlet,  flowRatelnletVelocity,  etc. 
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Base  type 


patch 

wall 


1 


symmetry 

empty 

wedge 

cyclic 

processor 


fixedValue 

fixedGradient 

zeroGradient 

Primitive  type 

directionMixed 

calculated 


Derived  type  e.g.  inletOutlet 


Figure  4.13:  Boundary  patch  hierarchy  in  an  OpenFOAM  case  (reproduced  from  Reference  13) 

4.4.2  Setting  Up  Boundary  Conditions  for  an  OpenFOAM  Case 

As  discussed  in  the  previous  Section,  the  OpenFOAM  mesh  conversion  utility, 
fluent  3  DMeshToFoam,  is  capable  of  recognising  the  "base  type"  of  each  boundary  patch. 
This  means  that  boundary  surfaces  with  the  following  attributes:  wall;  symmetry  plane;  and 
periodic  (cyclic);  are  automatically  setup  in  the  boundary  file.  However,  all  other  derived 
types,  such  as:  velocity  inlet,  pressure  inlet,  pressure  outlet,  etc,  from  ANSYS  Fluent  are 
assigned  a  basic  type  of  patch  in  the  boundary  file.  Whilst  each  of  these  boundary 
condition  types  carries  a  specific  numerical  definition  in  ANSYS  Fluent,  they  are  not  made 
available  to  the  public.  Therefore,  a  set  of  numerical  boundary  conditions  that  is 
considered  to  be  equivalent  to  that  in  ANSYS  Fluent  was  investigated. 

In  addition  to  setting  up  the  "base  type"  for  each  of  the  boundary  surfaces  in  the 
boundary  file,  a  "numerical  type"  must  also  be  assigned  for  each  of  the  field  variables  at 
each  of  the  boundary  surfaces  included  in  the  mesh.  Setting  up  the  numerical  boundary 
conditions  in  OpenFOAM  involves  creating  a  series  of  text  files  in  a  "O"  directory  as 
previously  shown  in  Figure  3.7.  An  example  of  an  OpenFOAM  case  that  was  used  for 
validating  the  rotorDiskSource  code  has  also  been  enclosed  in  this  report  (in 
Appendix  B),  and  may  serve  as  a  template  for  setting  up  future  cases.  Further  details  on 
the  more  specific  format  of  these  boundary  condition  files  are  provided  at  Chapter  5.2  of 
the  OpenFOAM  User  Guide  at  Reference  13. 

Table  4.3  provides  a  map  translating  the  commonly  used  ANSYS  Fluent  boundary 
conditions  to  those  that  are  readily  available  in  OpenFOAM.  The  OpenFOAM  boundary 
conditions  shown  in  the  map  are  not  exhaustive,  and  are  typically  the  simplest  available 
types.  There  is  very  limited  information  on  some  of  these  boundary  conditions  available  in 
the  OpenFOAM  User  Guide  (Reference  13,  Chapter  5.2).  Thus,  in  the  author's  opinion,  the 
simplest  way  to  learn  more  about  the  types  of  boundary  conditions  that  are  available  in 
OpenFOAM  and  their  numerical  implementation  is  through  the  source  code.  The  source 
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code  for  all  available  boundary  conditions  in  OpenFOAM  can  be  found  at  the  following 
path: 


$ { FOAM_SRC} / f initeVolume/ fields/ fvPatchFields /derived 

The  method  and  entries  required  to  set  up  a  boundary  condition  in  OpenFOAM  are  not 
necessarily  uniform  across  all  types.  However,  description  of  such  methods  required  to 
setup  each  boundary  condition  available  in  OpenFOAM  is  considered  to  be  beyond  the 
scope  of  the  current  report.  Nonetheless,  the  sample  cases  provided  in  Appendix  B  of  this 
report  provide  some  examples  on  how  the  boundary  conditions  are  typically  set  up  in  a 
case  involving  a  helicopter  in  forward  flight.  The  boundary  conditions  setup  can  be  found 
in  the  files  located  inside  the  "0"  directory  of  the  case  as  given  in  Appendices  B.2.6 
through  B.2.12.  These  files  need  to  be  created  manually  in  every  case  set  up.  The  methods 
required  for  specifying  any  other  boundary  conditions  apart  from  those  included  in 
Appendix  B  can  always  be  obtained  from  the  source  code. 

4.4.3  Rotor  Disk  Boundary  Conditions  in  OpenFOAM 

The  construction  of  the  rotor  disk  geometry  as  shown  in  Figure  4.8  and  Figure  4.9  requires 
construction  of  several  internal  surfaces  bounding  the  disk.  Following  the  meshing  of  the 
rotor  disk,  it  is  customary  to  define  these  disk  internal  surfaces  as  "interior"  type 
boundaries  in  ANSYS  Gambit  and  ANSYS  TGrid.  Unfortunately,  there  is  currently  no 
boundary  condition  in  OpenFOAM  that  is  equivalent  to  the  "interior"  type  that  is 
available  in  ANSYS  Fluent  (and  most  of  other  commercial  CFD  packages,  such  as  ANSYS 
CFX).  Any  "interior"  type  boundaries  in  the  ANSYS  Fluent  mesh  will  be  ignored  during 
the  conversion;  hence  such  boundary  will  not  appear  in  the  "polyMesh/boundary"  file 
in  the  OpenFOAM  mesh. 

However,  the  geometry  definition  of  the  surface  of  such  boundaries  is  retained  in  the 
OpenFOAM  mesh  in  the  form  of  a  "f  aceZone".  This  f  aceZone  may  still  prove  useful  for 
post-processing  the  result  using  paraview.  Therefore,  it  is  still  considered  to  be  beneficial 
to  place  the  "interior"  type  surface  or  boundary  when  creating  the  ANSYS  Fluent  mesh  for 
post-processing  purposes.  Section  4.6  will  provide  limited  guidance  on  how  an  "interior" 
surface  may  be  used  for  post-processing  in  OpenFOAM  using  paraview. 
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Table  4.3:  Mapping  ofANSYS  Fluent  boundary  conditions  to  standard  OpenFOAM  numerical  type  boundary  conditions 


ANSYS  Fluent 

OpenFOAM 

2.1.x 

"Base 

OpenFOAM  2.1.x 

"Numerical  Type"  in  Time  Directory  (If  simulation  is  started  from  0,  the  Time  Directory  is  0) 

BC  Type 

Type"  in 
constant/ 
polyMesh/ 
boundary 

0/p 

0/U 

0/k 

0/epsilon 

mass  flow  rate 
inlet 

patch 

zeroGradient; 

waveTransmissive^ 

flowRatelnletVelocity 

fixedValue; 

mappedFixedValue^; 

turbulentIntensityKineticEnergyInlet 

fixedValue; 

mappedFixedValue^; 

compressible:;turbulentMixingLengthDissipationRatelnlet* 

velocity  inlet 

patch 

zeroGradient; 

waveTransmissive' 

fixedValue; 

uniformFixedValue; 

mappedFixedValue^ 

fixedValue; 

mappedFixedValue^; 

turbulentIntensityKineticEnergyInlet 

fixedValue; 

mappedFixedValue^; 

turbulentMixingLengthDissipationRatelnlet* 

pressure  inlet 

patch 

fixedValue; 

totalPressure"' 

zeroGradient; 

pressurelnletVelocity^ 

outletinlet 

outletinlet 

pressure  outlet 

patch 

zeroGradient; 

totalPressure"'; 

inletOutlet; 

pressurelnletOutletVelocity** 

inletOutlet 

inletOutlet 

wall  -  no  slip 

wall 

zeroGradient 

fixedValue' 

fixedValue*; 

compressible::kqRWallFunction*° 

zeroGradient”; 

compressible;;epsilonWallFunction^° 

wall  -  slip 

wall 

slip 

slip 

slip 

slip 

interior 

N/A 

N/A 

N/A 

N/A 

N/A 

symmetry 

symmetry 

symmetryPlane 

symmetryPlane 

symmetryPlane 

symmetryPlane 

periodic 

cyclic 

cyclic 

cyclic 

cyclic 

cyclic 

N/A 

empty*^ 

empty 

empty 

empty 

empty 

N/A 

wedge^^ 

wedge 

wedge 

wedge 

wedge 

Table  continues  over  page. . . 
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...Table  continued 


ANSYS 

Fluent 

BC  Type 

OpenFOAM 

2.1.x 

"Base 

Type"  in 
constant/ 
polyMesh/ 
boundary 

OpenFOAM  2.1.x 

"Numerical  Type"  in  Time  Directory  (If  simulation  is  started  from  0,  the  Time  Directory  is  0) 

0/omega 

0/T 

0/mut 

0/alphat 

mass  flow 
rate  inlet 

patch 

fixedValue; 

mappedFixedValue^; 

fixedValue; 

mappedFixedValue^; 

calculated 

calculated 

compressible::turbulentMixingLengthDissipationRatelnlet^ 

totalTemperature"' 

velocity  inlet 

patch 

fixedValue; 

fixedValue; 

calculated 

calculated 

mappedFixedValue^; 

mappedFixedValue^; 

pressure  inlet 

patch 

outletinlet 

zeroGradient; 

calculated 

calculated 

outletinlet; 

inletOutletTotalTemperature’^ 

pressure 

outlet 

patch 

inletOutlet 

zeroGradient; 

inletOutlet; 

inletOutletTotalTemperature'^; 

calculated 

calculated 

wall  -  no  slip 

wall 

zeroGradienf; 

zeroGradient; 

mutKWallFunction“; 

alphatWallFunction; 

compressible:;epsilonOmegaFunction'° 

compressible::temperatureThermoBaffle1D^^ 

mutUWallFunction^*^ 

alphatJayatillekeWallFunction 

wall  -  slip 

wall 

slip 

slip 

slip 

slip 

Note: 

1 .  waveTransmissive  is  a  boundary  conditions  that  may  be  used  if  strong  pressure  reflection  on  the  boundary  is  detected  during  the  simulation,  that  causes 
numerical  instability  to  develop.  Othenwise,  the  use  of  zeroGradient  is  recommended. 

2.  mappedFixedValue  is  used  when  the  distribution  of  the  “value”  across  the  boundary  is  not  uniform  and  is  known.  For  example:  parabolic  velocity  inlet. 
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3.  The  compressible::turbulentMixingLengthDissipationRatelnlet  can  only  be  used  for  compressible  flow  solvers  (e.g.  rhoSimpleFoam).  If  an  incompressible  flow 
solver  is  used  (e.g.  simpleFOAM),  use  the  equivalent  turbulentMixingLengthDissipationRatelnlet. 

4.  totalPressure  and  totalTemperature  should  be  used  when  running  a  compressible  flow  solver. 

5.  Use  pressurelnletVelocity  for  U  when  totalPressure  is  used  for  p. 

6.  Use  pressurelnletOutletVelocity  for  U  when  totalPressure  is  used  for  p. 

7.  Set  value  to  “uniform  0”. 

8.  Set  turbulent  kinetic  energy  at  the  wall  (k)  to  zero  only  when  the  mesh  resolution  at  the  wall  is  adequate  to  resolve  the  flow  to  the  wall  (low  Reynolds  number 
mesh).  Otherwise,  use  wall  function. 

9.  Use  zeroGradient  for  epsilon  and/or  omega  at  the  wall  only  when  the  mesh  resolution  at  the  wall  is  adequate  to  resolve  the  flow  to  the  wall  (low  Reynolds  number 
mesh).  Otherwise,  use  wall  function. 

10.  These  BCs  are  for  compressible  flow  solvers.  When  running  an  incompressible  flow  solver,  remove  the  “compressible::”  from  the  BC  type  name. 

11.  Use  inletOutletTotalTemperature  on  a  pressure  boundary  when  totalTemperature  is  specified  at  an  inlet  boundary. 

12.  BC  for  calculating  ID  normal  conduction  through  a  thin  wall.  zeroGradient  condition  for  temperature  at  a  wall  will  result  in  an  adiabatic  wall. 

13.  BC  for  the  “front”  and  “back”  planes  of  a  planar  2D  mesh  -  only  used  in  a  2D  simulation. 

14.  BC  for  the  wedge  planes  of  an  axisymmetric  2D  mesh  -  only  used  in  a  2D  axisymmetric  simulation. 

15.  Wall  function  for  turbulent  vicosity  based  on  near  wall  values  of  turbulent  kinetic  energy  (k). 

1 6.  Wall  function  for  turbulent  vicosity  based  on  near  wall  values  of  velocity. 
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4.5  Solution  Driving  Strategy 

4.5.1  Overview 

The  steady-state  RANS  solvers  included  in  the  standard  OpenFOAM  distribution  are 
pressure-based  segregated  solvers  that  are  based  on  the  SIMPLE  algorithm.  The  numerical 
stability  of  such  RANS  algorithm  is  often  determined  by  a  range  of  interacting  factors. 
These  factors  are  generally  associated  with: 

1.  appropriateness  of  the  boundary  conditions  chosen; 

2.  appropriateness  of  the  chosen  initial  condition; 

3.  the  orthogonality  of  the  cell  faces  in  the  mesh; 

4.  the  number  of  PDEs  being  solved  simultaneously  during  the  simulation; 

5.  the  method  of  solving  the  coupled  PDEs,  either  by  using  a  segregated  method 
(explicit  coupling  with  quasi-linearisation)  or  direct  implicit  coupling  method; 

6.  selection  of  the  numerical  discretisation  scheme  for  each  term  in  the  PDEs  being 
solved; 

7.  selection  of  linear  solvers  employed  in  the  algorithm,  and 

8.  selection  of  the  under-relaxation  factors. 

The  original  SIMPLE  method  was  first  introduced  by  Patankar  and  Spalding  at  Reference 
16.  The  method  was  further  extended  for  compressible  flow  and  heat  transfer  application 
at  Reference  17.  However,  its  suitability  is  often  only  limited  to  weakly  compressible  flow 
(Ma  <  0.7).  In  general,  the  SIMPLE  algorithm  seeks  to  convert  the  continuity  equation  into 
an  equation  for  pressure  (often  referred  to  as  "pressure  corrector"),  and  to  use  the 
corrected  pressure  to  correct  the  initial  solution  of  the  momentum  equation.  The  solution 
is  then  iterated  until  a  "converged  solution"  is  reached,  meaning  the  pressure  corrector 
becomes  zero  anywhere  in  the  solution.  This  particular  method,  while  proven  to  be  low- 
cost  and  effective  in  solving  the  steady-state  version  of  the  Navier-Stokes  equations,  is 
inherently  unstable  because  the  solution  may  change  abruptly  from  one  iteration  to  the 
next,  leading  to  a  divergence  in  the  calculation.  Therefore,  an  appropriate  combination  of 
solver  settings  and  solution  control  methods  needs  to  be  applied  to  the  case  to  stabilise  the 
run. 

Unfortunately  due  to  the  diverse  flow  regimes  (even  when  the  simulated  flow  is  only 
limited  to  the  incompressible  and  compressible  flow  regimes),  there  is  no  single  method 
that  will  ensure  a  stable  simulation  for  all  possible  flow  conditions  and  flow  regimes  while 
at  the  same  time  maintaining  a  reasonable  accuracy  of  the  solution.  Eor  example,  using  a 
Gauss  upwind  discretisation  scheme  (1®‘  order  accurate  scheme)  for  all  convective  terms  in 
the  momentum  equation  may  lead  to  a  more  numerically  stable  run  than  using  a  Gauss 
linear  scheme  (2"^  order  accurate  scheme).  However,  this  may  lead  to  a  less  accurate 
solution  as  the  upwind  scheme  introduces  a  higher  degree  of  numerical  diffusion  (artificial 
diffusion)  in  the  solution.  An  alternative  method  would  be  to  start  the  run  with  a  Gauss 
upwind  scheme  for  the  convective  terms  until  the  pressure  field  is  fully  developed  in  the 
domain,  then  switching  to  the  Gauss  linear  scheme  in  the  more  advanced  stage  of  the 
iteration  to  get  a  better  converged  solution.  The  numerical  stability  may  also  be  enhanced 
by  heavily  under-relaxing  the  pressure  field,  which  may  dampen  any  numerical 
fluctuations  that  occur  in  the  pressure  solution. 
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In  an  OpenFOAM  case,  the  numerical  discretisation  schemes  are  specified  in  the 
fvSchemes  file  located  inside  the  system  directory  of  the  case.  The  linear  solver  settings 
and  solution  control  methods  are  set  using  the  fvSolution  file  located  inside  the 
system  directory  of  the  case.  Users  will  need  to  create  these  files  manually  following  the 
specifications  given  in  Section  4.4  and  Section  4.5  of  the  OpenFOAM  User  Guide 
(Reference  13).  While  the  User  Guide  (Reference  13)  provides  some  explanations  of  the 
numerical  schemes  and  linear  solver  settings  that  are  available  in  OpenFOAM,  they  are  by 
no  means  exhaustive.  Therefore,  it  may  also  be  useful  to  refer  to  the  sample  case  files 
provided  in  Appendix  B  of  this  report. 

The  following  sub-sections  will  discuss  some  of  the  more  important  considerations  that 
may  help  in  stabilising  the  steady  RANS  simulation  in  OpenFOAM  using  the 
simpleFoam  or  rhoSimpleFoam  solvers.  These  strategies  are  generally  applicable,  but 
not  limited,  to  cases  typically  considered  by  IRS  A,  e.g.  transport  of  hot  exhaust  plumes 
around  a  helicopter  in-flight. 

4.5.2  Appropriateness  of  Boundary  Conditions 

Inappropriate  boundary  conditions  are  the  most  common  cause  for  numerical  instability  in 
performing  a  steady  RANS  simulation.  This  difficulty  with  setting-up  proper  boundary 
conditions  for  a  problem  set  has  largely  been  alleviated  in  a  lot  of  market-leading 
commercial  CFD  packages  (such  as  ANSYS  Fluent  or  ANSYS  CFX)  for  many  commonly 
considered  flow  cases.  Many  of  the  commercial  CFD  packages  now  employ  an  extensive 
use  of  GUI  to  simplify  the  case  set  up  procedure,  and  at  the  same  time  automate  the 
process  of  setting  up  the  numerical  boundary  condition  type  for  each  of  the  field  variables. 
The  main  reasoning  behind  this  automation  is  to  minimise  the  chance  of  human  error  by 
minimising  the  amount  of  user's  input.  However,  this  has  an  adverse  effect  of  obscuring 
the  actual  implementation  of  the  boundary  conditions  from  the  user. 

In  OpenFOAM,  the  user  has  the  ability  to  set  every  boundary  condition  that  is  required  to 
solve  each  equation  (refer  to  Section  4.4).  However,  this  may  also  lead  to  inappropriate 
specification  of  boundary  conditions  which  causes  the  system  of  equations  to  be 
"numerically  stiff",  and  eventually  leading  to  a  divergence  solution  during  the  iteration. 
To  minimise  the  chance  of  setting-up  a  numerically  stiff  case,  the  user  needs  to  consider 
the  following  factors: 

1.  Avoid  using  a  Dirichlet  type  condition  (e.g.  f  ixedValue)  for  both  the  pressure  and 
velocity  on  a  boundary.  For  example,  if  a  f  ixedValue  velocity  is  set  at  an  inlet 
boundary,  a  zeroGradient  pressure  must  be  selected  on  that  boundary. 

2.  A  case  must  not  have  fixedValue  pressure  being  setup  on  all  boundaries  in  a 
computational  domain,  nor  a  zeroGradient  pressure  being  setup  on  all 
boundaries. 

3.  If  the  flow  is  compressible,  a  totalPressure  boundary  condition  must  be  used 
for  pressure  on  all  inlet  and  outlet  boundaries  (refer  to  Table  4.3). 
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4.  Use  the  inletOutlet  or  pressurelnletOutletVelocity  type  boundary 
conditions  for  velocity  on  a  pressure  boundary  for  incompressible  flow  and 
compressible  flow  cases  respectively.  This  is  particularly  important  on  boundaries 
where  "back- flow"  is  expected.  This  is  because  the  inletOutlet  type  is  a 
"mixed  condition"  that  sets  a  zeroGradient  condition  on  the  boundary  face  if  the 
face  flux  vector  on  that  face  is  pointing  out  of  the  domain,  and  sets  a  f  ixedValue 
condition  if  the  face  flux  vector  on  that  face  is  pointing  into  the  domain  (i.e. 
backflow).  inletOutlet  is  also  a  better  boundary  condition  for  turbulence 
quantities  across  a  pressure  boundary. 

5.  Ramp-up  the  velocity  (or  mass  flow  rate)  at  the  inlet  boundary  by  using  the 
"timeVarying"  set  up  of  the  fixedValue  or  f lowRatelnletVelocity 
boundary  conditions.  An  example  of  how  to  use  the  time-varying  option  with  the 
f  lowRatelnletVelocity  is  shown  at  Figure  4.14.  Note  that  a  volumetric  flow 
rate  (instead  of  a  mass  flow  rate)  must  be  defined  for  f  lowRatelnletVelocity 
when  used  with  an  incompressible  flow  solver  (e.g.  simpleFoam). 

4.5.3  Appropriateness  of  Initial  Condition 

An  initial  condition  must  be  set  for  each  of  the  field  variables  being  solved.  The  initial 
conditions  are  set  up  using  the  keyword  internalField  (refer  to  the  sample  case  setup 
at  Appendix  B).  The  simplest  type  of  initial  condition  in  OpenFOAM  is  as  follows: 

internalField  "uniform  (0  0  0)"  for  a  vector  field; 
internalField  "uniform  0"  for  a  scalar  field. 

Starting  the  simulation  from  a  zero  solution  is  known  to  potentially  cause  numerical 
instability  in  the  flow-field  at  later  stages  during  the  iteration.  Regions  in  the  flow-field 
with  strong  gradients  (such  as  the  engine  exhaust  exit  plane  in  a  helicopter  simulation)  are 
particularly  prone  to  numerical  instability.  Therefore,  where  a  complex  simulation  is 
concerned  (such  as  flow  around  a  helicopter  in  forward  flight  with  hot  exhaust  plume),  it 
is  recommended  that  the  solution  is  developed  gradually.  In  such  a  scenario,  the 
simulation  may  be  started  from  a  quiescent  condition  by  first  running  a  potential  flow 
solver  (potentialFoam)  or  incompressible  flow  solver  (simpleFoam)  without  modelling 
the  compressible  flow  feature.  This  will  initially  establish  the  pressure  field  and  rough 
wake  field  around  the  helicopter.  The  incompressible  solution  can  subsequently  be 
mapped  or  interpolated  into  a  new  compressible  flow  case  with  the  exhaust  plume 
activated.  Ramping  up  the  exhaust  plume  flow  rate  will  also  aid  in  stabilising  the  run. 

The  standard  distribution  of  OpenFOAM  comes  with  a  utility  to  map  or  interpolate  field 
solution  between  meshes  or  cases.  The  following  command  can  be  used  to  map  fields: 

$  mapFields  -consistent  -sourceTime  <time>  -targetTime  <time> 
<sourceCasePath> 
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$  cat  $FOAM_CASE/0/U 


L"- 


FoamFi 1 e 

{ 

version  2.0; 

format  ascii; 

class  voivectorFieid; 

object  U; 


\\  /  F  ield 

\\  /  O  Deration 

\\  /  A  nd 

\\/  M  anipulation 


- C++  - 

openFOAM:  The  open  source  cfd  Toolbox 

version:  1.7.0 

web:  www.OpenFOAM.com 


dimensions 


[0  1  -1  0  0  0  0]; 


//  Example  of  turbine  exit  -  Non-ramped  Mass  Flow  Rate  inlet 

turbxit 

{ 

type 
fl owRate 
value 

} 


f  1  owRat  el  nlet  velocity; 

2.85;  //  mass  flow  rate  -  kg/s 

uniform  (0  0  0); 


//  Example  of  turbine  exit  -  Ramped  Mass  Flow  Rate  inlet 

turbxit 

{ 

type  flowRateinletvelocity; 

flowRate  tableFile; 

tableFileCoeffs 

{ 

fileName  "$  FOAM_CASE/f 1 owRat  eRamptabl e " 

outof Bounds  clamp; 

value  uniform  (0  0  0); 

} 


I########################################################################### 
$  cat  $FOAM_CASE/fl owRat eRampTable 


(  0 
(  100 
C  200 
(  500 

(  1000 
(  1500 


0.0 
0.  5 
1.  0 
1.  5 
2.0 
2.85 


Figure  4.14:  Using  the  "timeVarying"  option  of  the  flowRateinletvelocity  boundary 
condition  across  a  mass  flow  rate  inlet  boundary 


4.5.4  Cell  Orthogonality  Consideration 

Highly  non-orthogonal  cells  (i.e.  skewed  cells)  may  lead  to  large  interpolation  errors  in  the 
calculation  of  the  cell  face  flux  for  discretising  both  the  convective  and  diffusive  terms.  The 
cell  quality  is  largely  controlled  and  inspected  during  the  meshing  process.  However,  it 
may  not  be  possible  to  completely  avoid  the  inclusion  of  highly-skewed  cells  in  a  mesh 
containing  highly  complex  geometry.  Therefore,  a  correction  needs  to  be  applied  in  the 
solving  stage. 

The  standard  OpenFOAM  utility  for  checking  mesh  quality  is 
$  checkMesh 
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The  user  must  observe  the  reported  average  value  and  maximum  value  of  the  mesh 
non-orthogonality  from  running  the  checkMesh  utility.  An  average  value  of  less  than  30 
is  considered  good.  At  least  1  or  2  nonOrthogonalCorrectors  are  needed  when 
checkMesh  reports  an  average  value  of  higher  than  50.  The  number  of 
nonOrthogonalCorrectors  can  be  set  in  the  "system/fvSolution"  file  of  the  case, 
under  the  keyword  nNonOrthogonalCorrectors. 

If  checkMesh  reports  a  maximum  cell  non-orthogonality  of  higher  than  50,  it  is 
recommended  that  a  leastSquares  method  is  used  for  calculating  the  gradient  terms, 
instead  of  the  Gauss  linear  scheme.  The  discretisation  scheme  for  the  gradient  term  is 
set  in  the  case  "system/ fvSchemes"  file,  under  the  keyword  gradSchemes. 

4.5.5  Selection  of  Numerical  Discretisation  Scheme 

OpenFOAM  requires  the  user  to  set  up  the  discretisation  schemes  that  are  to  be  used  for 
each  PDF  being  solved.  These  include  all  gradient  terms,  convective  terms  {divergence 
term),  diffusion  terms  {laplacian  term),  and  surface  normal  gradient  terms.  The  numerical 
schemes  are  specified  in  the  "system/ fvSchemes"  file  for  each  case. 

Section  4.4  of  the  OpenFOAM  User  Guide  (Reference  13)  contains  some  limited 
explanations  on  the  numerical  discretisation  setup  in  a  case.  An  example  of  the 
fvSchemes  file  has  also  been  included  in  the  attached  sample  case  files  at  Appendix 
B.2.14. 

There  are  several  differences  in  the  way  the  discretisation  schemes  are  setup  (or  selected) 
in  OpenFOAM  and  ANSYS  Fluent  cases.  A  map  translating  the  commonly  used  ANSYS 
Fluent  numerical  schemes  (or  discretisation  schemes)  to  those  that  are  readily  available  in 
OpenFOAM  is  shown  in  Table  4.4.  Due  to  the  limited  information  available  from  the 
ANSYS  Fluent  manual,  some  educated  judgement  was  applied  to  deduce  the  possible 
implementation  of  the  same  discretisation  scheme  in  Fluent. 

It  is  considered  a  standard  practice  to  start  a  complex  flow  simulation  (using  steady 
pressure-based  RANS  formulation)  with  first  order  accurate  schemes  for  the  divergence 
terms  (i.e.  Gauss  upwind).  The  residuals  are  then  monitored  during  runtime.  The 
solution  may  be  restarted  using  higher  order-schemes  (such  as  Gauss  linear)  when  the 
residuals  have  shown  a  significant  drop  (approximately  by  two  orders  of  magnitude),  and 
any  instabilities  in  the  pressure  residuals  have  gradually  disappeared.  A  more 
conservative  approach  would  be  to  restart  the  solution  using  higher  order  schemes  from  a 
fully  converged  first  order  accurate  solution. 
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Table  4.4:  Mapping  ofANSYS  Fluent  discretisation  schemes  to  standard  OpenFOAM  discretisation  schemes  -  excluding  Laplacian  schemes 


Pressure-Velocity  Coupling:  Segregated  -  SIMPLE 

ANSYS  Fluent  -  Setup  in  GUI 

OpenFOAM  -  $FOAM_CASE/system/fvSchemes 

Numerical  Behaviour  of  OpenFOAM  Scheme 

Gradient 

grad(p);  grad(U) 

Green  Gauss  Node  Based 

Gauss  pointLinear 

Second  order,  Gaussian  integration  -  Using  Node  vaiues 

Green  Gauss  Cell  Based 

Gauss  linear 

Second  order,  Gaussian  integration  -  Using  Ceii  centre  vaiues 

Least  Squares  Cell  Based 

leastSguares 

Second  order,  ieast  squares  fitting 

N/A 

fourth 

Fourth  order,  ieast  squares  fitting 

Flux  Limiter  in  Gradient  Term 

Cell-to-Face  Limiting 

f  aceLimited  <gradScheme>  i 

Ceii  iimited  version  of  one  of  the  above  grad  schemes 

Ceii-to-Ceii  Limiting 

CellLimited  <gradScheme>  i 

Face  iimited  version  of  one  of  the  above  grad  schemes 

Cell  Centre-to-Face  Centre  Interpolation 

Unknown 

linear 

Centrai  differencing,  unbounded 

Unknown 

upwind  phi 

Upwind  differencing,  bounded 

Biending  of  centrai  differencing  and  bounded  upwind  differencing  based  on 
<factor>,  e.g. 

Unknown 

limitedLinear  <factor>  phi 

limitedLinear  0.5  phi 

Pressure 

div(U,p) 

Standard 

Gauss  upwind 

First  order,  upwind  differencing 

PRESTO! 

N/A 

Unknown 

Linear 

Gauss  linear 

Second  order,  centrai  differencing 

Second  Order 

Gauss  linear 

Second  order,  centrai  differencing 

Body  Force  Weighted 

Gauss  limitedLinear  1 

Unknown 

Table  continues  over  page. . . 
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Table  continued. . . 


ANSYS  Fluent  -  Setup  in  GUI 

OpenFOAM  -  $FOAM_CASE/system/fvSchemes 

Numerical  Behaviour  of  OpenFOAM  Scheme 

Momentum  (Vector  Field) 

div(phi,U) 

First  Order  Upwind 

Gauss  upwind  <fiuxLimiterScheme> 

First  order,  bounded 

Second  Order  Upwind 

Gauss  linearUpwind  <fluxLimiterScheme> 

First/second  order,  upwind  differencing  with  a  biending  function,  bounded 

N/A 

Gauss  linear 

Second  order,  centrai  differencing  for  face  fiux  term,  unbounded 

Power  Law 

N/A 

Unknown 

QUiCK 

Gauss  QUICK 

Second  order,  bounded 

Third  Order  MUSCL 

Gauss  MUSCL 

Second  order,  Totai  Variation  Diminishing  (TVD)  scheme,  bounded 

N/A 

Gauss  skewLinear 

First/Second  order,  upwind  differencing  with  skewness  correction,  bounded 

N/A 

Gauss  limitedLinearV 

First/Second  order,  TVD  scheme,  iimitedLinear  differencing,  bounded 

N/A 

Gauss  limitedCubicV 

First/Second  order,  TVD  scheme,  cubic  differencing  with  fiux  iimiter,  bounded 

N/A 

Gauss  SFCD 

First/Second  order,  Normaiised  Variation  Diminishing  (NVD)  scheme, 

Seif-Fiitered  Centrai  Differencing,  bounded 

N/A 

Gauss  vanLeerV 

First/Second  order,  NVD  scheme,  bounded 

k,  epsilon, 
omega,  energy 
(Scalar  Field) 

div(phi,k);  div(phi,epsilon); 
div(phi, omega);  div(phi,K); 
div((muEff*dev2(T(grad(U))))); 
div((muEff*dev2(grad(U).T()))) 

First  Order  Upwind 

Gauss  upwind  <fiuxLimiterScheme> 

First  order,  bounded 

Second  Order  Upwind 

Gauss  iinearUpwind  <fiuxLimiterScheme> 

First/second  order,  upwind  differencing  with  a  biending  function,  bounded 

N/A 

Gauss  iinear 

Second  order,  centrai  differencing,  unbounded 

Power  Law 

N/A 

Unknown 

QUICK 

Gauss  QUiCK 

Second  order,  bounded 

Third  Order  MUSCL 

Gauss  MUSCL 

Second  order,  Totai  Variation  Diminishing  (TVD)  scheme,  bounded 

N/A 

Gauss  cubicCorrected 

Fourth  order,  unbounded,  cubic  differencing 

N/A 

Gauss  skewLinear 

First/Second  order,  upwind  differencing  with  skewness  correction,  bounded 

N/A 

Gauss  iimitedLinear 

First/Second  order,  TVD  scheme,  iimitedLinear  differencing,  bounded 

N/A 

Gauss  iimitedCubic 

First/Second  order,  TVD  scheme,  cubic  differencing  with  fiux  iimiter,  bounded 

Table  continues  over  page. . . 
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Table  continued. . . 


ANSYS  Fluent  -  Setup  in  GUI 

OpenFOAM  -  $FOAM_CASE/system/fvSchemes 

Numerical  Behaviour  of  OpenFOAM  Scheme 

k,  epsilon, 
omega,  energy 
(Scalar  Field) 

div(phi,k);  div(phi,epsilon); 
dlv(phi, omega);  div(phi,K); 
div((muEff*dev2(T(grad(U))))); 
dlv((muEff*dev2(grad(U).T()))) 

N/A 

Gauss  SFCD 

First/Second  order,  Normalised  Variable  (NV)  scheme, 

Self-Filtered  Central  Differencing,  bounded 

N/A 

Gauss  limitedVanLeer  <LowerBound>  <UpperBound> 

First/Second  order,  NVD  scheme  for  strictly  bounded  scalar,  e.g. 

Gauss  limitedVanLeer  0.1  1.0 

Note: 

1.  The  shaded  row  was  found  to  be  the  most  robust  scheme  for  a  mesh  of  typical  industrial  type  and  quality. 
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The  central  differencing  interpolation  (Gauss  linear)  used  in  the  convective  flux 
reconstruction  is  second  order  accurate,  which  often  causes  numerical  oscillations  during  a 
steady  RANS  simulation.  On  the  other  hand,  the  upwind  differencing  scheme  does  not 
induce  numerical  oscillations,  but  is  numerically  very  diffusive.  Hence,  a  blend  between 
the  two  schemes  is  the  preferred  method  in  most  cases. 

The  simplest  method  to  blend  the  central  differencing  scheme  with  the  upwind 
differencing  scheme  is  by  introducing  a  blending  function  into  the  interpolation  scheme. 
This  method  is  implemented  in  the  Gauss  linearUpwind  scheme,  which  is  similar  to 
the  ANSYS  Fluent's  second  order  upwind  discretisation  scheme. 

Furthermore,  there  exist  a  large  number  of  other  flux  reconstruction  schemes,  such  as  the 
TVD  and  NVD  schemes,  that  attempt  to  apply  various  form  of  flux  limiting  schemes  to 
increase  the  boundedness  of  the  scheme.  While  these  schemes  may  reduce  numerical 
oscillations  and  at  the  same  time  achieve  higher  than  first  order  accuracy,  they  have  not 
been  found  to  be  significantly  more  robust  than  the  linearUpwind  scheme.  It  is  also 
important  to  note  that  the  overall  accuracy  of  the  Gauss  schemes  is  limited  to  second  order 
despite  the  use  of  higher  order  flux  reconstruction  schemes  (i.e. 
Gauss  cubicCorrected  scheme  will  still  be  second  order  accurate  despite  the  fourth 
order  accurate  interpolation  scheme  being  used). 

Generally,  in  the  author's  opinion,  the  bounded  second  order  linearUpwind  scheme 
with  a  faceLimited  option  provides  an  optimum  balance  between  numerical  stability 
and  order  of  accuracy.  However,  for  a  strictly  bounded  scalar,  such  as  turbulence  kinetic 
energy,  a  vanLeer  or  limitedLinear  TVD  schemes  may  provide  better  damping  to  any 
numerical  oscillation  that  may  arise  in  the  solution,  particularly  if  strong  gradients  are 
expected  to  occur  in  the  domain  (Reference  18). 

All  Laplacian  terms  have  been  excluded  from  Table  4.4  as  there  is  no  sufficient  information 
available  to  deduce  the  type  of  Laplacian  Schemes  used  in  ANSYS  Fluent.  In  OpenFOAM, 
a  numerical  scheme  must  be  specified  for  all  Laplacian  terms  found  in  the  PDFs  that  are 
being  solved.  These  are  also  specified  in  the  " system/ fvSchemes"  file  for  each  case.  The 
Gauss  scheme  is  the  only  choice  of  discretisation,  and  it  requires  a  selection  of  both  an 
interpolation  scheme  for  the  diffusion  coefficient,  and  a  surface  normal  gradient  scheme. 
The  following  example  illustrates  the  method  of  specifying  a  Laplacian  discretisation 
scheme  in  OpenFOAM. 

Consider  a  typical  Laplacian  term  found  in  the  incompressible  Navier-Stokes  Equation, 

V  •  (vV^) 

This  is  represented  in  OpenFOAM  syntax  as: 
laplacian (nu, U) 
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The  Gauss  scheme  can  be  applied  to  the  above  Laplacian  term  by  applying  a  divergence 
scheme  to  the  velocity  gradient  term,  VU .  Note  that  the  term  VU  must  be  evaluated  as  a 

surface  normal  gradient  of  velocity  U  at  the  face  centre  (in  a  similar  fashion  to  the  flux 
evaluation  in  the  convection  term).  Thus,  to  summarise,  the  entries  required  are: 

laplacian (nu, U)  Gauss  <interpolationScheme>  <snGradScheme> ; 

The  interpolation  scheme  can  be  chosen  from  those  listed  in  Table  4.4.  It  is  recommended 
that  linear  interpolation  is  used.  The  user  must  then  specify  the  Surface  Normal 
Gradient  (snGrad)  scheme  from  those  listed  in  Table  4.5. 

Table  4.5:  Surface  normal  gradient  discretisation  schemes  for  specifying  Laplacian  schemes  in 
OpenFOAM 


OpenFOAM  -  $FOAM_CASE/system/fvSchemes  Numerical  Behaviour  of  OpenFOAM  Scheme 


snGrad  Scheme 


corrected 
uncorrected 
limited  <(^>' 
bounded 
fourth 


Unbounded,  second  order,  conservative 
Bounded,  first  order,  non-conservative 
Biending  of  corrected  and  uncorrected  schemes 
First  order  for  bounded  scaiars  ONLY 
Unbounded,  fourth  order,  conservative 


Note:  1.  The  shaded  row  was  found  to  be  the  most  robust  for  a  mesh  of  typical  industrial  type  and  quality. 
The  <ip>  corresponds  to  a  floating  point  number  between  0  and  1  (refer  to  the  following  paragraph  for  further 
explanation). 


The  "corrected"  and  "fourth"  snGrad  schemes  were  found  to  induce  numerical 
instability  when  used  with  an  unstructured  tetrahedral  mesh.  Therefore,  it  is 
recommended  that  the  limited  <ip>  scheme  is  used  for  most  cases.  According  to 
Reference  13,  the  blending  coefficient  {0<ip  <  1.0)  for  the  limited  scheme  is  based  on  the 
following  criteria: 


0  corresponds  to  uncorrected, 

0.333  non-orthogonal  correction  <  0.5  x  orthogonal  part, 

yj  =  < 

0.5  non-orthogonal  correction  <  orthogonal  part, 

^  1  corresponds  to  corrected. 

Selection  of  the  appropriate  blending  coefficient  to  use  should  be  based  on  the  cell 
orthogonality  measure.  As  a  rule  of  thumb,  when  the  maximum  non-orthogonality  in  the 
mesh  is  found  to  be  higher  than  50°,  the  "Gauss  linear  limited  0.5"  scheme 
should  be  used,  and  if  the  maximum  cell  non-orthogonality  is  found  to  be  higher  than  70°, 
the  "Gauss  linear  limited  0 . 3 3 3 "  should  be  used. 

The  simplest  way  to  test  the  appropriateness  of  the  choice  of  the  Laplacian  scheme  is  by 
running  a  potential  flow  solver  (i.e.  potentialFoam)  using  the  prepared  mesh.  The 

potentialFoam  solves  the  potential  flow  equation  (V^/>  =  0;V.t7  =  0),  which  is  the 
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Laplacian  of  the  pressure  (lap  lace  ( 1 ,  p)  Gauss  linear  limited  0.5;).  Thus, 

any  numerical  instability  that  arises  during  the  potentialFoam  simulation  is  solely  due 
to  the  discretisation  of  the  Laplacian  term. 


A  summary  of  the  optimum  second  order  discretisation  schemes  for  running  compressible 
flow  cases  typically  considered  within  the  IRSA  group  is  shown  in  Table  4.6.  Note  that 
since  the  momentum  source  introduced  by  the  rotorDiskSource  library  is  an  explicit 
source  term,  no  additional  discretisation  scheme  needs  to  be  specified  in  the  fvScheme 
file  apart  from  those  required  by  the  solver. 


Table  4.6:  Recommended  second  order  accurate  discretisation  scheme  set  up  for  use  with  the 
rhoSimpleFoam  solver 


Term  /  keyword  in  fvSchemes 

FV  Scheme 

Comment 

ddtSchemes 

default 

steadyState ; 

rhoSimpleFOAM  compressible  flow 
solver 

gradSchemes 

default 

cellLimited  Gauss  linear  1; 

Use  "cellLimited  Gauss 
pointLinear  1 "  if  Mach  >  0.5. 

grad (U) 

cellLimited  leastSquares  1; 

Cell-to-Cell  flux  limited  to  1 
neighbouring  cell.  LeastSquares  fit 
interpolation. 

grad (p) 

cellLimited  Gauss  linear  1; 

Can  be  changed  to  leastSquares  if 
large  number  of  highly  non-orthogonal 
cells  exist  in  the  mesh. 

grad (K) 

faceLimited  Gauss  linear  1; 

Cell-to-Face  flux  limited  to  1 
neighbouring  cell.  Linear  interpolation 
(central  differencing). 

divSchemes 

default 

none  ; 

div(phi,U) 

Gauss  linearUpwindV  grad{U); 

grad(U)  is  the  flux  limited  scheme  -  set 
in  the  gradSchemes. 

div(U,p) 

Gauss  linear; 

Use  Gauss  linear  only  to  maintain 
accuracy  for  the  pressure  equation. 

div (phi , k) 

Gauss  limitedLinear  0.5; 

The  coefficient  ''0.5''  can  be  reduced  to 
"0.1"  to  set  the  scheme  closer 
to  upwind  behaviour. 

Gauss  linearUpwind  with  flux  limiter 
can  also  be  used.  Alternatively,  use 

Gauss  vanLeer. 

div (phi , epsilon) 

Gauss  limitedLinear  0.5; 

The  coefficient  "0.5"  can  be  reduced  to 
"0.1"  to  set  the  scheme  closer 
to  upwind  behaviour. 

Gauss  linearUpwind  with  flux  limiter 
can  also  be  used.  Alternatively,  use 

Gauss  vanLeer. 

Table  continues  over  page. . . 
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Term  /  keyword  in  fvSchemes 

FV  Scheme 

Comment 

div (phi , omega ) 

Gauss 

limitedLinear  0 

1.5; 

The  coefficient  ''0.5''  can  be  reduced  to 
"0.1"  to  set  the  scheme  cioser 
to  upwind  behaviour. 

Gauss  linearUpwind  with  fiux  iimiter 
can  aiso  be  used.  Aiternativeiy,  use 

Gauss  vanLeer. 

div(phi,K) 

Gauss 

linearUpwind  grad(K); 

grad(K)  is  the  fiux  iimited  scheme  -  set 
in  the  gradSchemes. 

div (muEf f *dev2 (grad (U) . T ( ) ) ) ) 

Gauss 

linear; 

Use  Gauss  linear  oniy  to  maintain 
accuracy  for  the  turbuience  modeiiing. 

div (nuEff*dev (T (grad (U) ) ) ) ) 

Gauss 

linear; 

Use  Gauss  linear  oniy  to  maintain 
accuracy  for  the  turbuience  modeiiing. 

laplacianSchemes 

default 

none  ; 

Defauit  can  be  set  to  "Gauss  linear 
limited  0 . 333 ".  Aii  the  Other 

Lapiacian  entries  wiii  be  omitted. 

laplacian (muEf f , U) 

Gauss 

linear  limited 

0.333; 

Can  be  omitted  if  the  defauit  is  used,  it 
is  recommended  aii  iapiacian  terms 
used  the  same  scheme. 

laplacian ( (rho* (1/ |A(U) ) ) ,p) 

Gauss 

linear  limited 

0.333; 

Can  be  omitted  if  the  defauit  is  used. 

laplacian (alphaEf f , h) 

Gauss 

linear  limited 

0.333; 

Can  be  omitted  if  the  defauit  is  used. 

laplacian (DkEf f , k) 

Gauss 

linear  limited 

0.333; 

Can  be  omitted  if  the  defauit  is  used. 

laplacian (DepsilonEf f , epsilon) 

Gauss 

linear  limited 

0.333; 

Can  be  omitted  if  the  defauit  is  used. 

laplacian (DomegaEf f , omega) 

Gauss 

linear  limited 

0.333; 

Can  be  omitted  if  the  defauit  is  used. 

interpolationSchemes 

default 

linear; 

upwind  phi ; 

Can  be  changed  to  ieastSquares  for 
highiy  non-orthogonai  mesh  at  a  higher 
CPU  cost. 

"upwind  phi”  scheme  provides  a 
bounded  upwind  interpoiation. 

snGradSchemes 

default 

limited  0.333; 

fiux  iimited  scheme  with  non-orthogonai 
correction. 

4.5.6  Selection  of  Linear  Solvers 

The  type  of  linear  solver  used  for  solving  each  of  the  PDEs  must  be  specified  by  the  user  in 
the  "fvSolution"  file  located  in  the  "system"  directory  of  a  case.  Section  4.5  of 
Reference  13  contains  some  limited  explanations  on  the  setup  of  solution  method  for  a 
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case.  An  example  of  the  fvSolution  file  has  also  been  included  in  the  attached  case  files 
at  Appendix  B.2.15. 

There  are  several  differences  between  the  linear  solver  setup  in  OpenFOAM  and  ANSYS 
Fluent.  ANSYS  Fluent  by  default  sets  up  the  multigrid  solver  to  be  used  for  all  PDFs. 
While,  the  same  set  up  can  also  be  used  in  an  OpenFOAM  case,  it  is  not  a  recommended 
setting.  Table  4.7  shows  the  recommended  linear  solver  set  up  for  a  compressible 
OpenFOAM  case. 

4.5.7  Under-Relaxation  Factors 

Under-Relaxation  Factors  (URF)  can  be  used  to  stabilise  a  steady-state  RANS  simulation 
run.  In  an  OpenFOAM  case,  the  URFs  are  setup  in  the  "system/ fvSolution"  file  under 
the  keyword  "relaxationFactors". 

The  most  commonly  accepted  set  of  URFs  as  recommended  in  the  ANSYS  Fluent  User 
Manual  is  to  use  a  URF  of  0.3  for  pressure,  and  0.7  for  the  momentum  equation. 
Furthermore,  ANSYS  Fluent  recommends  using  a  URF  ranging  from  0.7  to  0.9  for  the 
energy  and  turbulence  model  equations.  This  particular  setup  has  been  found  to  be 
unsuitable  for  running  steady  highly  compressible  flow  cases  in  OpenFOAM.  Severe 
numerical  instability  growth  in  the  pressure  field  has  been  seen  in  the  early  iterations, 
which  eventually  led  to  numerical  divergence. 

A  recommended  URF  setup  for  running  a  steady  compressible  flow  case  using 
OpenFOAM  is  shown  in  Figure  4.15.  The  recommended  URF  for  pressure  is  ranging 
between  0.001  and  0.1.  Flow  cases  with  higher  Mach  numbers  will  tend  to  require  a  lower 
URF  for  pressure  during  the  early  iterations  (typically  for  the  first  1000  -  2000  iterations). 
The  URF  for  pressure  may  be  increased  in  the  later  iterations  to  speed  up  convergence. 


relaxationFactors 

{ 

fields 

{ 

P 

0. 001: 

rho 

} 

equati ons 

U 

1.  0 

0.3 

k 

0.  3 

epsilon 

0.3 

h 

0.  3 

omega 

0.3 

R 

0.  5 

nuTilda 

} 

} 

0.  5 

Figure  4.15:  Recommended  URF  setup  for  running  rhoSimpleSourceFoam  solver  for  a  moderately 
compressible  flow  case 
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Table  4.7:  Recommended  linear  Solver  Set  Up  for  Use  with  the 


Linear  Solver  Recommended  Setup 

Type  (optimised) 


P 


Preconditioned 
Conjugate 
Gradient 
Method  (PCG) 


{ 

solver  PCG; 
preconditioner 
{ 

preconditioner  GAMG; 
tolerance  1e-05; 

relTol  1e-03; 

smoother  DICGaussSeidel; 
nPreSweeps  0; 
nPostSweeps  2; 
nBottomSweeps  2; 
cacheAgglomeration  false; 
nCellsInCoarsestLevel  20; 
agglomerator  faceAreaPair; 
mergeLevels  1 ; 

} 

tolerance  1e-06; 
relTol  1e-02; 

} 
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Solver 


Alternative  Setups 


Comments 


solver  GAMG; 

tolerance  1e-06; 

relTol  1e-02; 

smoother  GaussSeidel; 
nPreSweeps  1; 
nPostSweeps  2; 
nBottomSweeps  2; 
cacheAgglomeration  true; 
nCellsInCoarsestLevel  20; 
agglomerator  faceAreaPair; 
mergeLevels  1 ; 


ALTERNATIVELY 


solver  PCG; 

//  Use  PBiCG  for  transonic 
preconditioner  DIC; 

//  Use  DILU  for  transonic 
tolerance  1e-06; 

relTol  1e-02; 


The  recommended  setup  uses  the  smoothed 
Geometric  Algebraic  Multi  Grid  (GAMG)  solver  as 
the  matrix  preconditioner  for  the  PCG  solver.  This 
results  in  a  highly  optimised  solution  method  for 
pressure  as  the  GAMG  preconditioner 
dramatically  reduces  the  number  of  PCG 
iterations  needed.  However,  the  user  may  opt  to 
use  the  GAMG  as  the  main  solver  as  a  cheaper 
alternative. 

Another  more  expensive  alternative  would  be  to 
use  the  PCG  solver  with  a  Cholevsky  method 
preconditioner  (DIC). 

If  the  maximum  Mach  Number  in  the  field  is 
higher  than  0.6,  it  is  recommended  that  the 
'transonic'  options  is  enabled  in  the 
system/fvSolution  file  by  adding  the  following 
entry: 

SIMPLE 

{ 

transonic  yes; 


If  the  transonic  option  is  enabled,  the  PBiCG 
solver  must  be  used  in  place  of  PCG.  The 
transonic  option,  when  enabled,  will  write  the  p 
matrix  in  its  full  non-symmetric  form. 

The  PCG  solver  is  only  for  soivng  a  symmetric 
matrix  equation,  while  the  PBiCG  is  the  PCG 
counterpart  for  solving  non-symmetric  matrix 
equation. _ 
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Linear  Solver 
Type 


U,  h,  k, 
epsilon, 
omega, 
R, 

nuTilda 


Geometric 
Algebraic 
Multi  Grid 
(GAMG)  Solver 


Table  continued. . . 


Recommended  Setup 
(optimised) 


Alternative  Setups 


"(U|h|k|epsilon|omega|R|nuTilda)" 

{ 

solver  GAMG; 

tolerance  1e-08; 

relTol  1e-02; 

smoother  GaussSeidel; 

nPreSweeps  1; 

nPostSweeps  2; 
nBottomSweeps  2; 
cacheAgglomeration  true; 
nCellsInCoarsestLevel  20; 
agglomerator  faceAreaPair; 

mergeLevels  1; 


"(U|h|k|epsilon|omega|R|nuTilda)" 

{ 


solver 

smoother 

tolerance 

relTol 


ALTERNATIVELY 


smoothSolver; 

GaussSeidel; 

1e-08; 

1e-02; 


"(U|h|k|epsilon|omega|R|nuTilda)" 

{ 


solver 

smoother 

tolerance 

relTol 


PBiCG; 

DILU; 

1e-07; 

1e-02; 


Comments 


It  is  recommended  to  use  the  the  same  solver 
type  for  U,h,  k,  epsilon,  omega,  and  R.  epsilon, 
omega,  or  R  must  be  specified  depending  on 
the  selection  of  turbulence  model. 

Note  that  the  expression 
"(U|h|k|epsilon|omega|R)"  represents  the 
boolean  operation  "or"  wildcard. 

The  recommended  setup  uses  the  GAMG 
solver  with  a  GaussSeidel  smoother.  A  cheaper 
alternative  is  to  use  the  Gauss-Seidel  solver 
(smoothSolver). 

Using  the  PBiCG  is  considered  to  be  the  most 
robust  and  accurate  solution  method,  however 
at  a  higher  computing  cost.  The  Incomplete 
L-U  Decomposition  method  (DILU)  can  be  used 
as  a  preconditioner  for  the  PBiCG  solver. 


If  any  instability  in  the  turbulence  quantities 
develops  during  a  simulation  run,  it  is 
recommended  to  create  a  separate  entry  for 
"(k|epsilon|omega|R)",  and  using  the 
smoothSolver  for  these  PDEs. 
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4.6  Plotting  Results  on  the  Rotor  Disk  Surface  using  Paraview™ 

Paraview^'^  is  a  third-party  post-processing  software  that  is  included  in  the  standard 
distribution  of  OpenFOAM.  An  extensive  user  guide  is  readily  available  from  the 
Paraview  official  website  at  Reference  19. 

The  discussion  here  will  be  limited  to  the  important  aspects  of  post-processing  results 
generated  using  the  rhoSimpleSourceFoam  solver  and  the  rotorDiskSource  library. 
Readers  are  assumed  to  have  a  working  knowledge  of  how  to  use  Paraview' s  basic 
functionality. 

As  previously  discussed  in  Section  4.3  and  Section  4.4,  the  rotor  disk  surfaces  are  created 
using  ANSYS  TGrid  as  "interior"  type  surfaces.  Since  OpenFOAM  does  not  recognise  an 
interior  type  surface  as  a  boundary  condition,  the  rotor  disk  surfaces  are  translated  into  a 
"f  aceZone"  during  the  mesh  translation  routine. 

Two  methods  are  available  in  Paraview  for  plotting  the  flow-field  variables  on  the  rotor 
disk  surface,  i.e.: 

1.  By  defining  a  new  plane  source^  in  Paraview  which  has  the  same  dimensions,  position 
and  orientation  as  the  rotor  disk  surface.  This  method  can  be  difficult  to  implement  if 
the  exact  position  and  orientation  of  the  disk  is  unknown. 

2.  By  converting  the  rotor  disk  region  contained  in  the  OpenFOAM  mesh  into  a  VTK 
format,  which  can  then  be  readily  read  into  Paraview.  This  is  the  preferred  method,  as 
the  disk  surface  mesh  and  geometrical  information  preserved  as  a  faceZone  in  the 
OpenFOAM  mesh  can  then  be  read  directly  in  the  Paraview  environment. 


4.6.1  Plotting  Flow-field  Variables  on  the  Rotor  Disk  using  a  New  Plane  Source  in 
Paraview 

After  loading  up  the  OpenFOAM  case  and  data  into  Paraview,  a  new  rotor  disk  surface 
plane  can  be  defined  in  Paraview  by  selecting  the  following  menu  entry: 

Sources  >  Disk 

The  dimensions,  radial  resolution  and  circumferential  resolution  of  the  newly  created 
plane  source  must  be  set  to  correspond  to  the  rotor  disk  mesh.  Following  this,  the  user 
must  then  apply  a  "transform"  filter  to  the  newly  created  disk  to  re-position  and  re-orient 
the  disk  to  the  correct  location  and  orientation.  This  can  be  done  through  the  following 
menu  entry: 

Filters  >  Alphabetical  >  Transform 


^  The  term  "source"  in  Paraview  refers  to  a  geometry  definition  (for  example:  a  surface  plane, 
cylinder,  etc.)  that  is  created  exclusively  within  the  Paraview  environment. 
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Finally,  the  flow-field  data  can  be  mapped  onto  the  newly  created  disk  using  the  following 
menu  entry: 

Filters  >  Alphabetical  >  Resample  With  Dataset 

Note  that  for  the  "Resample  With  Dataset"  filter  to  work,  the  user  must  first  select  the 
main  case  name  entry  in  the  Selection  Tree. 

4.6.2  Plotting  Flow-field  Variables  on  the  Rotor  Disk  using  a  VTK  File 

To  use  this  method,  the  OpenFOAM  mesh  containing  the  rotor  disk  source  region  must 
first  be  exported  into  a  VTK  format.  This  can  be  done  using  the  following  command  from 
the  root  directory  of  the  corresponding  OpenFOAM  case: 

$  foamToVTK  -latestTime 

The  foamToVTK  utility  will  write  the  mesh  and  point  data  into  a  new  directory  named 
VTK.  Inside  the  VTK  directory,  each  patch  and  face  Zone  is  arranged  into  a  separate 
directory.  The  user  must  then  identify  the  name  of  the  f  aceZone  that  corresponds  to  the 
rotor  disk  surface.  The  VTK  file  that  is  located  inside  the  directory  with  the  faceZone 
name  contains  the  point  and  cell  data  for  the  corresponding  faceZone  surface. 

The  newly  created  VTK  file  can  be  read  into  the  Paraview  environment  using  the  standard 
"file  >  open"  menu  entry  in  Paraview,  and  can  be  subsequently  used  as  the  "source"  for 
the  "Resample  With  Dataset"  filter  as  previously  described  in  Section  4.6.1. 

This  method  is  more  efficient  than  the  previous  one  as  it  does  not  require  the  user  to  know 
the  exact  position  and  orientation  of  the  rotor  disk  surface. 


UNCLASSIFIED 


81 


UNCLASSIFIED 

DSTO-TR-2931 

5.  Validation  and  Verification  Test  Case 

5.1  Overview 

An  experimental  dataset  based  on  a  rotor  -  fuselage  aerodynamic  interaction  study  is 
available  from  References  20  through  24.  This  dataset  was  identified  as  a  suitable 
validation  case  for  the  rotorDiskSource  model  in  OpenFOAM.  The  same  case  has  been 
previously  used  by  the  ANSYS  Fluent  team  at  Reference  2  for  validating  the  Fluent  VBM 
model. 

The  validation  effort  consists  of  modelling  the  wind  tunnel  experiment  described  in 
Reference  20  (which  will  be  referred  to  hereafter  as  the  Georgia  Tech  case)  using  both 
OpenFOAM  and  ANSYS  Fluent.  The  results  from  both  CFD  packages  will  be  compared  to 
the  experimental  data.  The  OpenFOAM  result  will  also  be  compared  to  the  ANSYS  Fluent 
result  for  verification  purposes.  The  ANSYS  Fluent  VBM  Model  (version  9.0)  provided  by 
ANSYS  directly  (Reference  25)  was  used  in  this  work. 

5.2  Summary  of  Georgia  Institute  of  Technology  (Georgia  Tech)  Rotor- 
Airframe  Interaction  Experimental  Setup 

The  wind  tunnel  experiment  in  Reference  20  involves  placement  of  a  simple  fuselage  body 
in  a  2.3  m  x  2.74  m  low  speed  wind  tunnel  with  a  uniform  freestream  velocity.  The  tunnel 
freestream  turbulence  level  was  measured  to  be  below  1  per  cent. 

A  two-bladed  teetering  rotor  was  placed  above  the  fuselage  to  simulate  a  helicopter  rotor. 
Using  this  setup,  the  rotor  and  the  airframe  were  linked  solely  through  the  flow-field. 
Figure  5.1  shows  a  schematic  of  the  experimental  setup,  which  has  been  reproduced  from 
Reference  20. 

According  to  References  20,  22  and  23,  the  fuselage  geometry  was  a  cylinder  with  a 
hemispherical  nose.  The  cylinder  diameter  was  134  mm.  The  total  length  of  the  fuselage 
was  1,350  mm.  The  rotor  hub  was  located  274.2  mm  above  the  fuselage,  and  was  placed 
along  the  fuselage  symmetry  line,  at  an  axial  length  of  914  mm  downstream  from  the 
fuselage  nose  tip. 

The  rotor  blade  was  made  with  an  un-tapered  NACA  0015  profile,  with  an  86  mm  chord 
length.  The  rotor  diameter  was  914  mm.  The  blade  hub  diameter  was  24.5  mm.  The  blade 
collective  pitch  angle  was  preset  at  10  degrees  during  the  experiment.  The  rotor  plane  was 
tilted  at  6  degrees  forward  to  simulate  the  forward  flight  condition,  and  the  rotor  speed 
was  set  at  a  constant  2100  rpm.  In  the  experiment  reported  in  Reference  22,  the  advance 
ratio  (which  is  defined  as  the  ratio  of  the  tunnel  freestream  velocity  to  the  rotor  tip  speed) 
was  set  to  0.10.  This  advance  ratio  was  for  a  turmel  freestream  velocity  of  10  m/ s. 

During  the  experiment,  coning  of  the  blade  was  measured  to  be  negligible  due  to  the 
stiffness  of  the  blade  and  the  absence  of  hinges  at  the  rotor  hub;  however,  the  blade  was 
free  to  flap  laterally  and  longitudinally.  The  blade  flapping  angles  were  measured  by 
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tracking  the  position  of  the  blade  tip.  Reference  23  reported  that  the  blade's  longitudinal 
and  lateral  flapping  angles  were  4.06  deg  and  2.03  deg  upwards  respectively. 

The  cylindrical  fuselage  in  Reference  23  was  instrumented  with  94  static  pressure  taps. 
Furthermore,  velocity  field  measurements  at  several  locations  in  the  flow-field  were  taken 
using  the  Laser  Doppler  Velocimetry  (LDV)  technique. 


2.74m 


a)  View  from  upstream  b)  Top  view 


Figure  5.1:  Georgia  Tech  rotor  -  airframe  interaction  wind  tunnel  experimental  setup  -  reproduced 
from  Reference  23 

5.3  CFD  Model 

5.3.1  Geometry  and  Mesh 

A  CFD  model  of  the  Georgia  Tech  experiment  was  created  as  part  of  the  current  validation 
effort.  The  geometry  and  mesh  were  created  using  the  ANSYS  Gambit  and  TGrid 
software.  The  mesh  was  then  converted  to  an  OpenFOAM  mesh  using  the 
f  luentBDMeshToFoam  utility. 

Unstructured  tetrahedral  cells  were  used  to  mesh  the  entire  computational  domain,  which 
comprises  of  approximately  1.4  million  cells.  The  tetrahedral  cells  in  the  domain  and  on 
the  fuselage  wall  were  then  converted  to  unstructured  polyhedral  cells  to  increase 
computational  efficiency.  The  rotor  domain  mesh  was  of  structured  hexahedral  type  with 
approximately  30,000  cells.  The  computational  domain  was  a  5.5m  x  2.7m  x  2.3m  block. 
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Figure  5.2  shows  the  mesh  configuration  used  in  this  CFD  model.  The  teeter  hinge  used  to 
mount  the  rotor  was  not  modelled  in  the  computational  domain. 


Figure  5.2:  Mesh  configuration 


5.3.2  Boundary  Conditions 

Dirichlet  and  Zero  Neumann  boundary  conditions  were  used  for  velocity  and  pressure 
respectively  across  the  domain  inlet  boundary.  The  velocity  at  the  outlet  boundary  was  set 
to  Zero  Neumann  condition,  while  the  gauge  pressure  across  the  outlet  boundary  was  set 
to  a  uniform  fixed  value  of  0  Pa. 

The  standard  k-e  turbulence  model  was  used  in  the  simulation.  Dirichlet  conditions  were 
used  for  k  and  e  at  the  inlet  boundary.  The  k  value  at  the  inlet  was  estimated  using 
Equation  5.1  to  be  12  / s^  based  on  10  m/s  tunnel  freestream  velocity  and  1%  upstream 
turbulence  intensity. 


^  =  1  inlet  X  I,urt  f  [Equation  5.1] 

(Reference  26) 

2  3 

The  e  value  at  the  inlet  was  estimated  using  Equation  5.2  to  be  32  m  /s  based  on  tunnel 
hydraulic  diameter  of  3  m,  and  freestream  turbulence  kinetic  energy  of  12  m^/ s^. 
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s  =  7 - r  [Equation  5.2] 

(O.OVxD^) 

(Reference  26) 
where: 

is  the  tunnel  hydraulic  diameter, 

is  a  k-e  model  constant  (commonly  accepted  value  is  0.09). 

Zero  Neumann  conditions  were  used  for  k  and  e  at  the  outlet  boundary. 

Non-slip  wall  conditions  were  used  on  all  the  domain  boundaries  except  at  the  domain 
inflow  and  outflow  boundaries.  Zero  Neumann  conditions  were  used  for  pressure  at 
walls,  while  the  velocity  is  set  to  zero.  The  standard  k  and  e  wall  functions  were  used  on 
all  walls.  The  computed  turbulent  viscosity,  u,  was  fitted  with  a  standard  wall  function  on 
the  wall. 

The  boundary  condition  set  up  for  the  Georgia  Tech  case  is  provided  at  Appendices  B.2.6 
through  B.2.12. 

5.3.3  Rotor  Modelling 

All  of  the  rotor  modelling  parameters  that  are  measured  in  the  experiment  (summarised  in 
Section  5.2)  can  be  incorporated  into  the  VBM.  It  is  important  to  point  out  that  the  pitch 
angle  of  the  teetering  rotor  in  the  Georgia  Tech  experiment  was  fixed  at  10°  collective 
without  any  possibility  of  adjusting  the  cyclic  pitch.  The  same  collective  pitch  was  entered 
as  a  rotor  parameter  in  the  VBM;  however,  the  cyclic  pitch  has  been  assumed  to  be  zero. 

The  2D  lifting  line  and  drag  curves  for  the  NACA  0015  airfoil  were  obtained  from  rurming 
a  2D  panel  method  code  called  XEoil.  The  Cl  and  Cd  profiles  for  a  range  of  AOA  are 
shown  in  Eigure  5.3. 

5.3.4  FV  Discretisation  Scheme  and  Linear  Solvers 

The  same  EV  discretisation  schemes  as  those  presented  in  Table  4.6  were  used  to  run  the 
Georgia  Tech  case. 

The  pressure  equation  was  solved  using  the  Geometric- Algebraic  Multi  Grid  solver  with  a 

Gauss-Seidel  smoother.  All  the  other  equations  were  solved  using  an  iterative  Gauss- 

Seidel  method  (smoothSolver).  The  iterative  solver  tolerances  were  set  to  10'^  for  the 

-8 

pressure  solver,  and  10'  for  all  the  other  equations. 

An  under  relaxation  factor  of  0.2  was  used  for  the  pressure  field  during  the  simulation  run. 
All  other  field  variables  were  under-relaxed  by  a  factor  of  0.3  during  runtime. 


UNCLASSIEIED 


85 


UNCLASSIFIED 

DSTO-TR-2931 

Samples  of  the  FV  discretisation  scheme  and  linear  solver  setup  for  the  Georgia  Tech  case 
are  provided  at  Appendix  B.2.14  and  Appendix  B.2.15  respectively. 


O 


♦OpenFQAM  Pro¬ 
file  2  (NACA  0015) 
-▼-OpenFOAM  Pro¬ 
file  1  (NACA  0015) 
-•-Fluent  Profile 
(NACA  0015) 


♦  OpenFOAM  Profile 
2(NACA0015) 

▼  OpenFOAM  Profile 
1  (NACA  0015) 
-♦-Ruent  Profile 
(NACA  0015) 
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Figure  5.3:  Cl  and  Cd  profiles  for  NACA  0015  airfoil  over  a  range  ofAOA 

5.3.5  ANSYS  Fluent  Case  Setup 

For  verification  purposes,  an  identical  mesh  and  geometry  to  that  used  in  OpenFOAM  was 
setup  and  run  using  ANSYS  Fluent.  In  ANSYS  Fluent,  the  equations  were  initially 
discretised  using  first  order  upwind  schemes.  The  schemes  were  later  changed  to  second 
order  upwind  after  1000  iterations.  The  Multi-Grid  solver  was  used  for  all  equations  in 
ANSYS  Fluent. 

5.3.6  Solution  Driving  Strategy  and  Residual  Trend 

The  OpenFOAM  case  was  initially  run  for  1000  iterations  using  the  Gauss  upwind  (first 
order  upwind)  scheme  for  all  the  divergence  terms.  The  schemes  were  then  switched  to 
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the  Gauss  linearUpwind  (second  order  upwind)  scheme  from  the  1000*  iteration 
onwards,  until  convergence  was  achieved.  The  Flow-field  convergence  was  observed  after 
4000  iterations. 

Figure  5.4  shows  the  residual  curves  for  an  OpenFOAM  run  of  the  untrimmed  Georgia 
Tech  case.  The  residuals  are  seen  to  exhibit  cyclic  behaviour  at  convergence,  possibly  due 
to  some  unsteadiness  in  the  flow-field  which  cannot  be  modelled  using  the  steady-state 
RANS  model. 


Figure  5.4:  Residual  curves  of  the  Georgia  Tech  case  run  using  the  rhoSimpleSourceFoam  solver 

5.4  Verification  and  Validation  Result 

The  Georgia  Tech  Rotor- Airframe  experiment  was  simulated  for  both  the  untrimmed  rotor 
and  trimmed  rotor  conditions.  In  the  untrimmed  rotor  simulation,  the  blade  collective  and 
cyclic  pitch  angles  were  set  to  the  experimentally  measured  values.  However,  in  the 
trimmed  rotor  simulation,  the  blade  collective  and  cyclic  pitch  angles  were  allowed  to 
change  during  the  simulation  until  the  experimentally  measured  total  rotor  thrust  was 
obtained  in  the  simulation.  Due  to  the  lack  of  data,  the  rotor  pitching  and  rolling  moments 
in  the  experiment  were  assumed  to  be  zero  for  the  trimmed  rotor  condition  (See 
Section  5.4.3). 

5.4.1  Calculated  Rotor  Thrust  and  Moments 

A  comparison  between  converged  rotor  disk  thrust  and  moments  obtained  using  different 
solvers  is  shown  in  Table  5.1.  It  shows  that  the  predicted  rotor  thrust  obtained  using  the 
simpleFoam  (incompressible)  solver  for  the  untrimmed  condition  compares  well  with  the 
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experimentally  measured  value  of  72.8  N.  The  rho  Simple  Foam  (compressible)  solver  and 
ANSYS  Fluent  are  shown  to  under-predict  the  rotor  thrust. 

Table  5.1:  Calculated  rotor  thrust  and  moments 


Untrimmed 

/Trimmed? 

Blade  Cyclic 
Pitch  Angles 

Blade 

Total  Rotor  Disk 

Flow  Solver 

Collective 

Angle 

Thrust  (N) 

Pitching 

Moment 

Rolling 

Moment 

(N.m) 

(N.m) 

Untrimmed 

0° (Lat  and 

1 

Long) 

2.37°  (Lat) 
-2.88  (Long) 

10°^ 

71.96 

2.72 

-2.08 

simpleFoam 

(Incompressible) 

Trimmed 

12° 

72.8  ^ 

0 

0 

Untrimmed 

0°  (Lat  and 

1 

Long) 

2.24°  (Lat) 
-2.54  (Long) 

10°^ 

66.93 

2.46 

-1.99 

rhoSimpleSourceFoam 

(Compressible) 

Trimmed 

11.2° 

72.8^ 

0 

0 

ANSYS  Fluent 
(Incompressible) 

Untrimmed 

0°  (Lat  and 

1 

Long) 

10°^ 

68.158 

3.05 

-3.32 

Note: 

1 .  Based  on  experimentally  measured  values  (Reference  24). 

2.  Based  on  experimentally  measured  Coefficient  of  Thrust  of  0.0092  (Reference  24). 

5.4.2  Untrimmed  Rotor  Simulation  Result 
Pressure  Field 


The  mean  static  gauge  pressure  contour  plots  on  the  x-z  plane  and  on  the  y-z  plane  passing 
through  the  rotor  disk  centre  for  the  untrimmed  rotor  run  are  shown  in  Figure  5.5  and 
Figure  5.6  respectively. 

The  figures  show  that  the  mean  pressure  field  obtained  using  OpenFOAM  and  ANSYS 
Fluent  compare  favourably.  Furthermore,  result  obtained  using  the  modified  OpenFOAM 
compressible  flow  solver  (rhoSimpleSourceFoam)  was  also  shown  to  be  similar  to  that 
obtained  using  the  incompressible  flow  solver  (simpleFoam). 

From  Figure  5.5,  the  effect  of  the  forward  tilt  of  the  rotor  disk  plane  is  seen  by  the 
formation  of  a  low  pressure  region  at  the  forward  tip  of  the  rotor  disk  plane.  Furthermore, 
Figure  5.6  shows  that  the  lateral  pressure  distribution  is  not  symmetrical  although  no 
lateral  tilt  is  present  on  the  rotor  disk.  The  lateral  pressure  imbalance  on  the  rotor  disk  is 
consistent  with  the  predicted  non-zero  disk  moments  in  the  calculation.  However,  the 
actual  rotor  moments  acting  on  the  disk  were  not  measured  during  these  experiments; 
hence  further  comparison  is  prevented. 
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Figure  5.5:  Mean  static  gauge  pressure  contour  plot  on  the  x-z  plane  which  passes  through  the 
rotor  disk  centre 
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Figure  5.6:  Mean  static  gauge  pressure  contour  plot  on  the  y-z  plane  which  passes  through  the 
rotor  disk  centre 

Fuselage  Coefficient  of  Pressure 

The  mean  Coefficient  of  Pressure  (Cp)  on  the  fuselage  was  experimentally  measured  and  is 
available  from  Reference  24.  The  mean  pressure  distribution  was  measured  on  the  top  and 
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bottom  surfaces,  and  on  the  port  and  starboard  sides  of  the  fuselage.  Figure  5.7  shows  the 
contour  plot  of  Cp  and  pressure  tapping  locations  on  the  fuselage.  The  Cp  on  the  fuselage 
was  defined  as  follows: 


C 


p 


[Equation  5.3] 


(Reference  24) 


Cp 

-0.4  0  0.4  0.8 


Note: 

The  red  and  blue  lines  on  the  fuselage  indicate  locations  of  static 
pressure  taps  during  the  Georgia  Tech  experiment 


Figure  5.7:  Computed  mean  Cp  on  the  fuselage  without  force  and  moment  trimming 

Figure  5.8  shows  a  comparison  between  the  CFD  computed  Cp  on  the  fuselage  and  the 
experimentally  measured  values.  The  comparison  shows  that  the  predicted  Cp  using  both 
the  OpenFOAM  incompressible  and  compressible  flow  solvers  compares  favourably  with 
the  ANSYS  Fluent's  prediction.  However,  both  the  OpenFOAM  and  ANSYS  Fluent  results 
have  failed  to  capture  the  experimentally  measured  pressure  peaks  on  the  top  and  port 
sides  of  the  fuselage.  According  to  Reference  24,  the  disagreements  in  the  pressure  peaks 
occur  at  the  locations  where  the  blade  tip  vortices  impinge  on  the  fuselage  body,  as 
illustrated  by  the  schematic  shown  at  Figure  5.9.  The  momentum  sources  introduced  by 
the  VBM  are  based  on  time-averaged  forces  acting  on  the  blade;  thus,  it  cannot  capture 
transient  flow  features,  such  as:  formation  of  the  blade  tip  vortices;  and  the  effect  of  the 
blade  passage  as  it  moves  through  air. 

According  to  Reference  11,  a  possible  explanation  of  the  strong  under-prediction  of  the 
pressure  peak  on  the  top  surface  of  the  fuselage  near  the  nose  is  that  it  is  due  to  the 
presence  of  a  periodic  tip  vortex  that  retards  the  freestream  airflow,  causing  a  rise  in  the 
stagnation  pressure  at  this  location. 

Furthermore,  although  the  blade  thickness  has  been  ignored  in  the  present  simulations, 
this  may  have  a  more  pronounced  effect  on  the  pressure  field  when  the  blade  is  passing  in 
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close  proximity  to  the  fuselage  surface.  At  this  instance,  the  narrow  space  between  the 
fuselage  and  the  blade  is  expected  to  create  a  "venturi  effect",  which  causes  local 
interaction  between  the  rotor  downwash  and  the  freestream  flow. 


Fuselage  Top 


1.5 


Fuselage  Bottom 


x/R 


Figure  5.8:  Comparison  of  measured  and  computed  mean  Cp  on  the  fuselage  without  force  and 
moment  trimming 


Figure  5.9:  Schematic  representation  of  the  instantaneous  flow-field  above  the  fuselage  - 
reproduced  from  Reference  22 
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A  comparison  between  the  gauge  static  pressure  contour  produced  using  ANSYS  Fluent 
and  the  simple  Foam  solver  on  the  top  surface  of  the  rotor  disk  is  shown  in  Figure  5.10. 
The  same  comparison  for  the  rotor  disk  bottom  surface  is  shown  in  Figure  5.11.  These 
figures  show  that  the  pressure  distribution  patterns  on  the  disk  surfaces  are  generally 
similar  in  both  the  ANSYS  Fluent  and  the  OpenFOAM  results.  However,  ANSYS  Fluent 
predicts  much  lower  pressure  occurring  on  the  front  part  of  the  disk  compared  to  that 
shown  in  the  OpenFOAM  result. 


Figure  5.10:  Gauge  static  pressure  contour  on  the  rotor  disk  top  surface 
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Velocity  Field 


Figure  5.12  shows  a  comparison  between  the  flow  streamlines  coloured  by  velocity 
magnitude  computed  using  OpenFOAM  and  ANSYS  Fluent.  It  can  be  seen  that  the  two 
results  compare  favourably  to  each  other,  albeit  there  are  slight  differences  in  the  colour 
contrast  and  line  thickness  between  the  two  results.  There  is  no  experimental  data 
available  that  enables  comparison  with  the  streamlines. 

The  "tip  vortices"  shown  in  Figure  5.12  are  not  the  blade  tip  vortices;  rather  these  are 
vortices  that  are  formed  due  to  the  pressure  gradient  that  exists  between  the  top  and 
bottom  surfaces  of  the  rotor  disk,  similar  to  those  formed  on  the  tip  of  a  fixed  wing.  The 
comparison  shows  that  generally  the  rotor  flow  is  convected  downstream  by  the 
freestream. 
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Figure  5.12:  Streamlines  coloured  by  velocity  magnitude.  Velocity  magnitude  contour  plot  is 
shown  on  the  rotor  disk  bottom  surface 
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Reference  20  provides  the  time-averaged  measurement  of  the  rotor  downwash  velocity 
normalised  by  the  freestream  velocity  at  a  plane  located  12.7  mm  below  the  rotor  disk. 
Contour  plots  of  the  rotor  downwash  velocity  were  generated  from  the  CFD  results  to 
enable  comparison  with  experimental  data.  This  comparison  is  shown  at  Figure  5.13. 


FWD  Side 


— 0>a  0.0  0.4  0.8  1.6 


Figure  5.13:  Contour  plot  of  mean  downwash  velocity  measured  12.7  mm  below  the  rotor  disk  - 
negative  values  denote  upflow 
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From  Figure  5.13,  the  OpenFOAM  result  generally  agrees  very  well  with  the 
experimentally  measured  values.  The  mean  downwash  velocity  distribution  is  shown  by 
both  the  CFD  results  and  the  experimental  data  to  be  asymmetrical  with  respect  to  the 
longitudinal  axis.  The  upflow  region  near  the  hub  is  clearly  seen  on  the  retreating  side  of 
the  rotor  disk.  There  is  also  an  upflow  region  observed  in  both  results  throughout  the  front 
part  of  the  disk.  According  to  Reference  20,  the  upflow  region  near  the  hub  is  largely 
attributed  to  the  flow  separation  on  the  blade  downstream  of  the  hub,  and  the  rotation 
imparted  to  the  flow  by  the  viscous  effect  near  the  hub. 

The  strongest  downwash  flow  is  shown  in  both  the  experimental  data  and  the  OpenFOAM 
result  to  occur  at  around  70  and  290  rotor  azimuth  degrees  towards  the  aft  side  of  the  disk, 
near  the  blade  tip. 

The  experimental  data  at  Reference  20  includes  a  plot  of  the  normalised  velocity  profile  at 
a  vertical  location  below  the  rotor  disk,  at  z/R=0.178  (refer  to  Figure  5.14).  The  profile  was 
measured  along  the  fuselage  body  centreline  axis.  The  same  plot  was  constructed  from  the 
CFD  results  and  compared  to  the  available  experimental  data.  This  comparison  is  shown 
in  Figure  5.15. 

From  Figure  5.15,  it  can  be  seen  that  OpenFOAM  under-predicts  the  streamwise  velocity 
component  compared  to  Fluent  by  approximately  14  per  cent.  However,  there  is  a  good 
agreement  between  the  Fluent  and  OpenFOAM  predicted  downwash  velocity  profile,  and 
the  experimentally  measured  values. 


ROTOR  DISC 


Figure  5.14:  Velocity  measurement  location  at  Reference  20 
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Figure  5.15:  Comparison  of  measured  and  computed  mean  dtreamwise  velocity  profile  (Top)  and 
downwash  velocity  profile  (Bottom)  at  Z/r=0.178 

5.4.3  The  Effect  of  Thrust  and  Moments  Trimming 

To  evaluate  the  performance  of  the  trimming  routine  incorporated  into  the  OpenFOAM 
VBM,  the  Georgia  Tech  case  was  re-run  with  force  and  moments  trimming  set  to  active. 
The  simulation  with  trim  calculation  was  started  from  a  quiescent  flow  condition  to  avoid 
any  hysteresis  effect  appearing  in  the  result.  The  trim  calculation  was  carried  out  every 
five  flow-iterations. 

As  previously  discussed,  the  trimming  routine  varies  both  the  collective  and  cyclic  pitch 
angles  until  the  target  rotor  thrust  and  moments  are  obtained.  Another  equivalent  method 
of  numerical  trimming  of  the  rotor  involves  solving  for  the  equation  of  motion  of  the  blade 
in  flapping  mode  by  accounting  for  the  aerodynamic  forces  acting  on  the  blade  and  the 
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blade  structural  response.  The  latter  method  may  not  always  be  achievable.  Often  this  is 
because  of  the  lack  of  blade  structural  data.  Nonetheless,  it  is  important  to  note  that  as  far 
as  the  mean  rotor  aerodynamic  behaviour  is  concerned,  one  degree  of  cyclic  pitch 
produces  the  same  aerodynamic  effect  as  one  degree  of  blade  flapping. 

In  the  context  of  the  present  validation  work,  the  cyclic  pitch  in  the  Georgia  Tech  teetering 
rotor  was  not  adjustable.  Furthermore,  the  total  moments  acting  on  the  teetered  rotor  were 
not  measured  experimentally.  Therefore,  the  present  simulation  assumes  that  the  total 
moments  acting  on  the  rotor  disk  are  zero. 

Table  5.2  shows  the  trim  parameters  that  were  used  in  the  OpenFOAM  simulation.  The 
effect  of  trimming  to  the  blade  collective  and  cyclic  pitch  angles  were  presented  previously 
in  Table  5.1. 

Table  5.2:  Rotor  trim  parameters  for  the  GIT  validation  case 


Trim  Parameter 

Value 

Target  Rotor  Thrust 

72.8  N 

Target  Rotor  Rolling  Moment 

0  N.m 

Target  Rotor  Pitching  Moment 

0  N.m 

Initial  Blade  Collective  Pitch 

5  deg 

Angle 

Initial  Longitudinal  Cyclic  Pitch 
Angle 

0  deg 

Initial  Lateral  Cyclic  Pitch  Angle 

0  deg 

Trim  Calculation  Interval 

5 

dTheta  (Perturbation  Angle) 

0.1 

Relaxation  Factor 

1 

Trim  Solver  Tolerance 

1.00E-06 

Pressure  Field 


Figure  5.16  provides  a  comparison  of  the  fuselage  Cp  obtained  from  simulations  with  the 
trimming  routine  active.  The  Cp  plots  were  generated  at  the  probe  locations  shown  in 
Figure  5.7.  A  comparison  between  Figure  5.8  (without  trim)  and  Figure  5.16  (with  trim) 
reveals  that  the  trimmed  result  matches  the  experimental  data  more  closely  than  the 
untrimmed  solution.  In  particular,  the  computed  pressure  distributions  on  the  top, 
starboard  side  and  port  side  of  the  fuselage  agree  well  in  the  trimmed  case  with  the 
experimental  data,  apart  from  the  pronounced  pressure  peaks  that  were  previously 
identified  to  have  been  caused  by  the  impingement  of  tip  vortices  on  the  fuselage. 
Furthermore,  it  is  also  shown  that  the  simple  Foam  solver  produces  results  that  are  closer 
to  the  experimental  data  than  the  rhoSimpleFoam  results. 

Minimal  differences  are  observed  in  the  pressure  distribution  on  the  bottom  surface  of  the 
fuselage  between  the  untrimmed  and  trimmed  results.  This  is  due  to  the  rotor  air-wake- 
fuselage  interaction  being  less  prominent  on  the  bottom  surface  of  the  fuselage. 
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Note: 

The  blue  dotted  lines  highlight  the  area  of  improvement  when 
compared  to  the  plotted  data  shown  previously  in  Figure  5.8. 


Figure  5.16:  Comparison  of  measured  and  computed  mean  Cp  on  the  fuselage  with  the  thrust  and 
moment  trimming  activated 


Velocity  Field 


The  effect  of  thrust  and  moments  trimming  on  the  downwash  velocity  profile  is  shown  in 
Figure  5.17.  The  figure  shows  that  no  significant  improvement  is  gained  by  activating  the 
thrust  and  moment  trimming.  However,  the  trim  feature  can  be  useful  if  the  blade 
collective  and  cyclic  pitch  angles  are  not  known,  but  the  rotor  disk  total  thrust  and 
moments  are  known. 
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Figure  5.17:  Comparison  of  measured  and  computed  streamwise  velocity  (Top)  and  downivash 
velocity  (Bottom)  at  Z/r=0.178  with  the  thrust  and  moment  trimming  activated 


Tip  Effect 

Eigure  5.18  shows  the  effect  of  using  a  tip  factor  of  0.96  instead  of  1.0  on  the  fuselage  Cp,  to 
account  for  the  loss  of  lift  near  the  blade  tip.  It  can  be  seen  from  this  figure  that  the 
predicted  Cp  trends  on  the  fuselage  top  and  port  side  surfaces  have  been  slightly 
improved  from  the  previous  results  shown  in  Eigure  5.16.  The  value  of  0.96  is  considered 
to  be  typical.  Therefore,  it  is  recommended  that  a  tip  factor  is  specified  in  the  simulation. 
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Figure  5.18:  Mean  Cp  on  the  fuselage  with  the  thrust  and  moment  trimming  activated  and  using  a 
tip  factor  of  0.96 
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6.  Conclusions  and  Recommendations 


A  new  OpenFOAM  library,  rotorDiskSource ,  has  been  developed  to  include  the  effect 
of  helicopter  rotor  flow  into  existing  OpenFOAM  steady-state  RANS  flow  solvers.  Being 
part  of  a  free  open-source  software  suite  allows  high  performance  computer  cluster 
hardware  to  be  used  at  minimum  cost.  This  allows  large-scale  whole-of-airframe 
computations  to  be  routinely  made  in  support  of  accurate  infrared  signature  modelling. 

In  the  new  library,  rotorDiskSource,  the  helicopter  rotor  is  approximated  as  a  thin  one- 
cell-thick  disk.  The  mean  flow  through  the  rotor  is  approximated  by  introducing  time- 
averaged  momentum  sources  on  the  rotor  disk,  which  are  calculated  based  on  the  two- 
dimensional  Blade  Element  Theory.  The  rotorDiskSource  model  incorporates  a  range 
of  blade  characteristics,  such  as:  the  blade  lifting  line  and  drag  profiles,  variations  in  the 
blade  collective  and  cyclic  pitch  angles,  blade  flapping  and  coning  effect,  as  well  as  rotor 
thrust  and  moments  trimming.  Integration  of  the  rotorDiskSource  library  into  existing 
OpenFOAM  RANS  flow  solvers  has  also  been  demonstrated. 

An  experimental  dataset  based  on  a  rotor  -  fuselage  aerodynamic  interaction  study  done  at 
the  Georgia  Institute  of  Technology  was  identified  as  a  suitable  validation  case  for  the 
rotorDiskSource  model  in  OpenFOAM.  The  same  case  has  been  previously  used  by 
the  ANSYS  Fluent  team  at  Reference  2  for  validating  the  Fluent  VBM  model.  The 
validation  effort  consists  of  modelling  the  Georgia  Tech  wind  turmel  experiment  using 
both  OpenFOAM  and  ANSYS  Fluent.  The  mean  velocity  and  pressure  fields  predicted  by 
both  OpenFOAM  and  ANSYS  Fluent  software  were  shown  to  agree  well  with  the  time- 
averaged  experimental  data.  However,  both  the  OpenFOAM  and  ANSYS  Fluent  models 
failed  to  capture  the  effect  of  vortex  shedding  from  the  blade  tip.  Nonetheless,  this 
shortcoming  is  to  be  expected  from  the  current  model,  as  only  time-averaged  momentum 
sources  are  being  introduced  on  the  rotor  disk.  The  VBM  is  also  not  expected  to  capture 
any  other  transient  flow  features. 

Having  completed  validation,  the  rotorDiskSource  library  is  being  used  to  model  the 
hansport  of  the  hot  exhaust  plume  around  various  ADF  helicopter  types  for  a  range  of 
flight  conditions.  An  example  whole-of-aircraft  flow-field  prediction  can  be  seen  for  the 
MRH-90  in  Figure  6.1  and  Figure  6.2.  The  details  of  these  results  and  related  modelling 
will  be  published  in  forthcoming  DSTO  reports. 
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Note:  Temperature  is  shown  in  Kelvin. 


Figure  6.1:  Flow  streamlines  coloured  by  temperature  used  for  visualising  the  interaction  between 
the  exhaust  plume  and  the  rotor  downwash  around  the  MRH-90  in  hover  outside  of 
ground  effect. 


Note:  1.  Temperature  is  shown  in  Kelvin. 

2.  The  exhaust  gas  is  visualised  using  iso-temperature  contour  plot. 

3.  The  prevailing  wind  is  relative  to  the  aircraft  heading. 


Figure  6.2:  Predicted  MRH-90  fuselage  temperature  in  hover  with  different  prevailing  relative 
wind  angles. 


UNCLASSIFIED 


103 


DSTO-TR-2931 


UNCLASSIFIED 


7.  References 


1.  Saripalli,  S.  R.,  "Virtual  Blade  Element  Model  Developments  to  Study  Rotor  Down 
Wash  Effects  (U)",  DSTO  Technical  Report,  DSTO-TR-2311,  June  2009. 

2.  Ruith,  M.  R.,  and  Wirogo,  S.,  "Unstructured,  Multiplex  Rotor  Source  Model  with  Thrust 
and  Moment  Trimming  -  Eluent's  VBE  Model,  AIAA  2005-5217,  23>'‘^  AIAA  Applied 
Aerodynamics  Conference,  Toronto,  Canada,  9  June  2005. 

3.  OpenCED,  http:/ / www.openfoam.com,  "OpenFOAM  Official  Website",  OpenFoam 
Foundation,  ESI,  Ltd.,  Erance. 

4.  Zori,  L.  A.  J.  and  Rajagopalan,  R.  G.,  "Navier-Stokes  Calculation  of  Rotor-Airframe 
Interaction  in  Eorward  Elight",  Journal  of  the  American  Helicopter  Society,  Vol.  40, 
Issue  2, 1995. 

5.  Wahono,  S.,  "CED  Simulation  of  MRH-90  in  Hover  using  OpenFOAM",  Draft  DSTO 
Technical  Report,  TBA. 

6.  Advanced  Rotorcraft  Technology,  Inc.,  "FlightLab",  Computer  Software,  March  2003. 

7.  Prouty,  R.  W.,  "Helicopter  Aerodynamics",  Second  Edition,  Phillips  Business 
information,  Inc.,  2007. 

8.  Rajagopalan,  R.  G.  and  Lim  C.  K.,  "Laminar  Plow  Analysis  of  a  Rotor  in  Hover", 
Journal  of  American  Helicopter  Society,  Vol  .36(1),  1991. 

9.  Rajagopalan,  R.  G.  and  Mahur,  S.  R.,  "Three  Dimensional  Analysis  of  a  Rotor  in 
Eorward  Plight",  Journal  of  American  Helicopter  Society,  Vol.  38,  Issue  3, 1993. 

10.  Poling  D.R.,  Rosenstein  H.  and  Rajagopalan  R.G.,  "Use  of  a  Navier-Stokes  Code  in 
Understanding  Tiltrotor  Plowfields  in  Hover",  Journal  of  American  Helicopter  Society, 
Vol.43,  pp.  103-109, 1998. 

11.  Ruith,  M.  R.,  "Unstructured,  Multiplex  Rotor  Source  Model  with  Thrust  and  Moment 
Trimming  -  Eluent's  VBM  Model",  Eluent  Technical  Notes,  TN293,  June  2005. 

12. Johnson,  W.,  "Helicopter  Theory",  Dover  Publications,  1994. 

13.0penCPD,  "OpenPOAM  User  Guide",  Version  2.1.1, 16  May  2012. 

14.0penCPD,  "OpenPOAM  Programmer's  Guide",  Version  1.6,  24  July  2009. 

15. OpenCED,  http:/ / www.openfoam.org/docs/cpp/,  "OpenPOAM  Source  Guide  - 
Doxygen",  OpenFoam  Foundation,  ESI,  Ltd.,  Prance. 

16. Caretto,  L.  S.,  Gosman,  A.  D.,  Patankar,  S.  V.,  and  Spalding,  D.  B.,  "Two  Calculation 
Procedures  for  Steady,  Three-Dimensional  Plows  with  Recirculation,  Proc.  3'''^ 
International  Conferences  for  Numerical  Methods  in  Pluid  Dynamics,  Paris,  1972. 

17. Patankar,  S.  V.,  "Numerical  Heat  Transfer  and  Pluid  Plow",  McGraw-Hill,  New  York, 
1980. 


104 


UNCLASSIPIED 


UNCLASSIFIED 


DSTO-TR-2931 


IS.Yee,  C.  S.,  Warming,  R.  F.,  and  Harten,  A.,  "Implicit  Total  Variation  Diminishing  (TVD) 
Schemes  for  Steady-State  Calculations",  NASA  Technical  Memorandum,  N83-23085, 
March  1983. 

19. Kitware,  Inc.,  http:/ / paraview.org/ paraview/help/ documentation.html,  "Paraview 
Official  Website". 

20. Liou,  S.  G.,  Komerath,  N.  M.,  and  McMahon,  H.  M.,  "Velocity  Measurements  of 
Airframe  Effects  on  a  Rotor  in  Low-Speed  Forward  Flight",  Journal  of  Aircraft,  Vol.  26, 
Issue.  4, 1989. 

21.  Brand,  A.,  Komerath,  N.  M.,  and  McMahon,  H.  M.,  "Results  from  Laser  Sheet 
Visualization  of  a  Periodic  Rotor  Wake",  Journal  of  Aircraft,  Vol.  26,  Issue.  5, 1989. 

22. Liou,  S.  G.,  Komerath,  N.  M.,  and  McMahon,  H.  M.,  "Velocity  Field  of  a  Cylinder  in  the 
Wake  of  a  Rotor  in  Forward  Flight",  Journal  of  Aircraft,  Vol.  27,  Issue.  9, 1990. 

23. Liou,  S.  G.,  Komerath,  N.  M.,  and  McMahon,  H.  M.,  "Measurements  of  the  Interaction 
Between  a  Rotor  Tip  Vortex  and  a  Cylinder",  AIAA  Journal,  Vol.  28,  Issue.  6, 1990. 

24. Mavris,  D.  N.,  Komerath,  N.  M.,  and  McMahon,  H.  M.,  "Prediction  of  Aerodynamic 
Rotor-Airframe  Interactions  in  Forward  Flight",  Journal  of  American  Helicopter 
Society,  October  1989. 

25.  Leap,  Pty.  Ltd.,  Fluent  VBM  UDF  Version  9.0,  Computer  Code,  Personal 
Communication  via  email,  5  January  2011. 

26.0penCFD,  "OpenFOAM  Andvanced  Training  Guide",  Version  1.6,  26  April  2010. 


UNCLASSIFIED 


105 


DSTO-TR-2931 


UNCLASSIFIED 


Appendix  A  Source  Code  for  the  rotorDiskSource 

A.l.  High  Level  Description  of  the  Source  Code  Files 

This  Appendix  contains  the  source  code  needed  for  the  implementation  of  the  VBM  in 
OpenFOAM  2.1.x.  The  code  needs  to  be  compiled  as  an  OpenFOAM  library  following  the 
instructions  given  in  Section  3.5.  Table  A.l  shows  a  complete  list  of  all  files  included  in  the 
overall  code  along  with  a  brief  description  of  the  content  of  each  file. 

A  hardcopy  of  all  files  is  included  in  Section  A.2  of  this  Appendix,  arranged  following  the 
order  shown  in  Table  A.l.  Comments  in  the  code  have  been  shown  in  blue  to  improve 
readability. 


Table  A.l:  Summary  of  all  source  files  in  the  rotorDiskSource  code 


File  Name 

Location 

Description 

rotorDiskSource. H 

rotorDiskSource 

Contains  the  class  definition  for  the  main 
rotorDiskSource  class.  It  is  derived  from  the 
basicSource  class. 

rotorDiskSource. C 

rotorDiskSource 

Contains  the  main  implementation  of  the 
rotorDiskSource  Class.  It  contains  the  class 
constructor  and  several  private  member  functions  and 
implementation  of  the  basicSource  class  virtual 
functions. 

The  basic  geometrical  information  of  the  rotor  disk 
radius,  centre,  orientation,  cell  face  areas  are  also 
subtracted  from  the  mesh  in  this  class.  These 
procedures  are  contained  in  the  following  private 
functions: 

rotorDiskSource::createCoordinateSystem(), 
rotorDiskSource:  :constructGeometry(),  and 
rotorDiskSource::setFaceArea(). 

The  momentum  source  calculation  is  included  in  the 
member  function  rotorDiskSource:  :calculate().  The 
momentum  source  is  added  to  the  solver  in  the 
function  rotorDiskSource::adSup(). 

rotorDiskSourceXemplates.C 

rotorDiskSource 

Contains  a  templated  function 
rotorDiskSource::writeField()  which  can  be  used  to 
write  out  to  external  data  file  any  variable  computed 
in  the  rotorDiskSource  class  as  a  field  variable. 

rotorDiskSourcel.H 

rotorDiskSource 

Contains  the  implementation  of  several  data  access 
functions  as  protected  public  member  functions. 

These  functions  are  handy  for  accessing  and  passing 
various  protected  and  private  data  in  the 
rotorDiskSource  to  any  external  classes. 

Table  continues  over  page  . . . 
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Table  continued  ... 


File  Name 

Location 

Description 

rotorDiskSource.dep 

rotorDiskSource 

This  file  was  automatically  generated  using  the  ivmake 
utility.  It  contains  a  list  of  all  dependencies  and  their 
corresponding  paths  to  the  other  standard 

OpenFOAM  classes  included  in  the  OpenFOAM  2.1.x 
standard  distribution. 

bladeModel.H 

rotorDiskSource/ 

bladeModel 

Contains  the  class  definition  of  bladeModel  class.  This 
class  is  the  container  class  for  various  blade  geometry 
features  as  defined  in  the  sourceProperties  file,  such 
as  the  blade  radial  section,  twist  angle  and  chord. 

bladeModel.C 

rotorDiskSource/ 

bladeModel 

Contains  the  constructor  for  bladeModel  class  and  a 
linear  interpolation  function.  Linear  interpolation  of 
the  chord  and  twist  angles  between  radial  sections  in 
the  rotor  disk  is  implemented  in  this  class. 

This  class  is  constructed  in  the  Foam::rotorDiskSource 
class  as  a  private  object  called  "blade_''.  The 
bladeModel::interpolate()  function  is  called  inside  the 
rotorDiskSource::calculate()  function. 

profileModel.H 

rotorDiskSource/ 
prof  ileMo  del 

Contains  the  class  definition  of  profileModel  class. 

This  class  is  the  container  class  for  various  lifting  and 
drag  line  profiles  as  defined  in  the  sourceProperties 
file. 

The  profileModel  class  is  an  abstract  class  for  the  two 
methods  of  specifying  the  blade  section  lift  and  drag 
coefficients  curves,  i.e.  the  "lookup"  method  and  the 
"series"  method. 

profileModel.C 

rotorDiskSource  / 
prof  ileMo  del 

Contains  the  constructor  for  profileModel  class  and  a 
virtual  function,  profileModel:  :Cdl()  which  calculates 
and  returns  the  Cd  and  Cl  for  a  given  AOA. 

This  class  is  constructed  in  the  Foam::rotorDiskSource 
class  as  a  private  object  called  "profile_".  The 
profileModel::Cdl()  function  is  called  inside  the 
rotorDiskSource::calculate()  function. 

prof  ileMo  delList .  H 

rotorDiskSource  / 
prof  ileMo  del 

Contains  the  class  definition  of  profileModelList  class. 
This  class  is  derived  from  the  template  Foam::PtrList 
class  which  takes  the  profileModel  class  as  its  type. 

prof  ileMo  delList .  C 

rotorDiskSource/ 
prof  ileMo  del 

Contains  the  constructor  for  profileModelList  class 
and  a  virtual  function, 

profileModelList::connectBlades()  which  sets  the 
bladeModel  -  to  -  profileModel  addressing. 

Table  continues  over  page  . . . 
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Table  continued  ... 


File  Name 

Location 

Description 

lookupProfile.H 

rotorDiskSource/ 
prof  ileMo  del/  lookup 

Contains  the  class  definition  of  lookupProfile  class, 
which  inherits  from  the  abstract  class 
Foam::profileModel.  This  class  holds  the  Cd,  Cl  and 
AOA  data.  This  class  is  only  constructed  during 
runtime  if  "lookup"  entry  is  specified  in  the 
sourceProperties  file. 

lookupProfile.C 

rotorDiskSource/ 
prof  ileMo  del/  lookup 

Contains  the  constructor  for  lookupProfile  class  and 
the  implementation  of  the  virtual  function 
Foam::profileModel::Cdl().  This  function  looks-up  the 
supplied  Cl,  Cd  Vs  AOA  data  from  the 
sourceProperties  file,  and  then  linearly  interpolates 
the  Cl  and  Cd  for  a  supplied  AOA. 

seriesProfile.H 

rotorDiskSource/ 
prof  ileMo  del/ series 

Contains  the  class  definition  of  seriesProfile  class, 
which  inherits  from  the  abstract  class 
Foam::profileModel.  This  class  holds  the  Cd,  Cl  and 
AOA  data.  This  class  is  only  constructed  during 
runtime  if  "series"  entry  is  specified  in  the 
sourceProperties  file. 

seriesProfile.C 

rotorDiskSource/ 
prof  ileMo  del/ series 

Contains  the  constructor  for  seriesProfile  class  and  the 
implementation  of  the  virtual  function 
Foam::profileModel::Cdl().  This  function  reads  the 
supplied  coefficients  for  calculating  Cl  and  Cd  for  a 
given  AOA  from  the  sourceProperties  file,  and  then 
calculate  the  Cl  and  Cd  based  on  the  Fourier  series 
equations  specified  in  Section  3.4.1. 

trimModel.H 

rotorDiskSource/ 

trimModel/ 

trimModel 

Contains  the  class  definition  of  trimModel  class.  This 
class  is  the  container  (abstract)  class  for  various  blade 
trimming  methods  as  defined  in  the  sourceProperties 
file. 

In  the  current  implementation,  there  are  two 
trimming  methods  available,  i.e.  the  "fixed  trim"  and 
the  "targetForce"  trim.  The  default  is  fixed  trim 
method,  which  is  equivalent  to  an  untrimmed 
solution. 

trimModel.C 

rotorDiskSource/ 

trimModel/ 

trimModel 

Contains  the  constructor  for  trimModel  class  and  a 
virtual  function,  trimModel:  :correct().  This  virtual 
function  returns  the  updated  blade  forces  when  called 
using  the  new  blade  pitch  parameters. 

This  class  is  constructed  in  the  Foam::rotorDiskSource 
class  as  a  private  object  called  "trim_". .  The 
trimModel::correct()  function  is  called  inside  the 
rotorDiskSource: :addSup ()  function. 

Table  continues  over  page  . . . 
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Table  continued  ... 


File  Name 

Location 

Description 

trimMo  delNew  .C 

rotorDiskSource/ 
trimModel/ 
trimMo  del 

Contains  a  procedure  to  create  "clones"  of  the 
trimModel  class  objects  during  runtime  to  account  for 
multiple  rotor  objects. 

fixedXrim.H 

rotorDiskSource/ 

trimModel/fixed 

Contains  the  class  definition  of  fixedXrim  class,  which 
inherits  from  the  abstract  class  Foam::trimModel.  Xhis 
class  reads  blade  collective  and  cyclic  pitch  angles 
from  the  sourceProperties  file,  and  returns  the 
geometric  angle  of  attack. 

Xhis  class  is  only  constructed  during  runtime  if 
"fixed"  trim  entry  is  specified  in  the  sourceProperties 
file. 

fixedXrim.C 

rotorDiskSource/ 

trimModel/fixed 

Contains  the  constructor  for  fixedXrim  class  and  the 
implementation  of  the  virtual  functions 
Foam::trimModel::alphag()  and 
Foam::trimModel::correct(). 

In  this  class,  the  Foam::trimModel::correct()  function 
does  nothing. 

targetForceXrim.H 

rotorDiskSource/ 

trimModel/ 

targetForce 

Contains  the  class  definition  of  targetForceXrim  class, 
which  inherits  from  the  abstract  class 

Foam::trimModel. 

Xhis  class  reads  blade  collective  and  cyclic  pitch 
angles  from  the  sourceProperties  file,  and  returns  the 
updated  geometric  angle  of  attack  after  a  force  and 
moments  trimming  calculation  is  carried  out. 

Xhis  class  is  only  constructed  during  runtime  if 
"targetForce"  trim  entry  is  specified  in  the 
sourceProperties  file. 

targetForceXrim.C 

rotorDiskSource/ 

trimModel/ 

targetForce 

Contains  the  constructor  for  targetForceXrim  class  and 
the  implementation  of  the  virtual  functions 
Foam::trimModel::alphag()  and 
Foam::trimModel::correct(). 

Xhe  implementation  of  the  force  and  moments 
trimming  using  the  Newton-Raphson  method  as 
described  in  Section  2.3.7  is  contained  in  the 
Foam::targetForceXrim::correct()  function  inside  this 
class. 

files 

rotorDiskSource/ 

Make 

Contains  a  list  of  .C  files  to  be  compiled  using  wmake 
libso.  Xhe  compiled  library  name  is  also  specified  in 
this  file. 

Options 

rotorDiskSource/ 

Make 

Contains  a  list  of  compiler  options  and  include  files  to 
be  included  in  the  library  compilation  using  wmake 
libso. 
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A.2.  Source  Code  for  the  rotorDiskSource 


A.2.1  rotorDiskSource.H 


/* 


*\ 


w  / 
w  / 
w  / 
w/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011-2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 

You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: : rotorDiskSource 
Description 

Cell  based  momentum  source 

Source  approximates  the  mean  effects  of  rotor  forces  on  a  cylindrical 
region  within  the  domain 

Sources  described  by: 

rotorDiskSourceCoef f s 
{ 


f ieldNames 

(U)  ; 

// 

names  of  fields  on  which  to  apply  source 

rhoName 

rho  ; 

// 

density  field  if  compressible  case 

nBlades 

3; 

// 

number  of  blades 

tipEf f ect 

0.96; 

// 

normalised  radius  above  which  lift  =  0 

inlet FlowType 

local ; 

■  // 

inlet  flow  type  specification 

geome  t  ryMode 

auto  ; 

// 

geometry  specification 

ref Direction 

(-1  0 

0)  ; 

11  reference  direction 

//  -  used  as  reference  for  psi  angle 

trimModel 

fixed ; 

■  // 

fixed  1 1  targetForce 

f lapCoef f s 
{ 


betaO 

0; 

// 

coning  angle 

[deg] 

betal 

0  ; 

// 

lateral  flapping  coeff 

beta2 

0  ; 

// 

longitudinal 

flapping  ' 

} 

blade 

{ 

} 

profiles 

{ 


Where : 

geometryMode  = 

auto  :  determine  rototor  co-ord  system  from  cells 

specified  :  specified  co-ord  system 
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inletFlowType  = 
fixed 

surf aceNormal 
local 


specified  velocity 

specified  normal  velocity  (positive  towards  rotor) 
use  local  flow  conditions 


SourceFiles 

rotorDiskSource . C 
rotorDiskSourceTemplates . C 


\* 


*/ 


#ifndef  rotorDiskSource_H 
#define  rotorDiskSource  H 


#include 

#include 

#include 

#include 

#include 

#include 

#include 


"basicSource . H" 
"cylindricalCS .H" 

" NamedEnum . H " 
"bladeModel . H" 
iiprof  ileModelList .  H" 
" volFieldsFwd . H" 
"dimensionSet . H" 


//*************************************// 


namespace  Foam 

{ 


//  Forward  declaration  of  classes 
class  trimModel; 


/* 

\* 


Class  rotorDiskSource  Declaration 


class  rotorDiskSource 
public  basicSource 

{ 

public : 

enum  geometryModeType 

{ 


gmAuto , 
gmSpecif ied 

}; 

Static  const  NamedEnum<geometry]yiodeType , 

enum  inletFlowType 

{ 

if Fixed, 

if Surf aceNormal , 
if Local 

}; 

Static  const  NamedEnum< inletFlowType,  3> 


2>  geometry]yiodeTypeNames_; 


inlet FlowTypeNames_; 


*\ 

*/ 


protected: 

//  Helper  structures  to  encapsulate  flap  and  trim  data 
//  Note:  all  input  in  degrees  (converted  to  radians  internally) 

struct  flapData  //  on-the-fly  data  encapsulation  declaration 

{ 

scalar  betaO;  //  coning  angle 

scalar  betal;  //  lateral  flapping  coeff 

scalar  beta2;  //  longitudinal  flapping  coeff 

}; 


//  Protected  data 

//-  Name  of  density  field 
word  rhoName_; 

//-  Reference  density  if  rhoName  =  'none' 
scalar  rhoRef_; 
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//-  Rotor  debug  mode 
bool  rotorDebug_; 

//-  Rotational  speed  [rad/s] 

//  Positive  anti-clockwise  when  looking  along  -ve  lift  direction 
scalar  omega_; 

//-  Number  of  blades 
label  nBlades_; 

//-  Inlet  flow  type 
inletFlowType  inletFlow_; 

//-  Inlet  velocity  for  specified  iinflow 
vector  inletVelocity_; 

//-  Tip  effect  [0-1] 

//  Ratio  of  blade  radius  beyond  which  lift=0 
scalar  tipEffect_; 

//-  Blade  flap  coefficients  [rad/s] 
flapData  flap_; 

//-  Cell  centre  positions  in  local  rotor  frame 
//  (Cylindrical  r,  theta,  z) 

List<point>  x_; 

//-  Rotation  tensor  for  flap  angle 
List<tensor>  R_; 

//-  Inverse  rotation  tensor  for  flap  angle 
List<tensor>  invR_; 

//-  Area  [m2] 

List<scalar>  area_; 

//-  Rotor  co-ordinate  system  (r,  theta,  z) 
cylindricalCS  coordSys_; 

//-  Maximum  radius 
scalar  rMax_; 

//-  A  list  of  psi  angle  in  the  rotor  zone  for  10 
List<scalar>  psiList_; 

// -  Trim  model 
autoPtr<trimModel>  trim_; 

//-  Blade  data 
bladeModel  blade_; 

//-  Profile  data 

prof ileModelList  profiles_; 

//-  Rotor  bank  angle 
scalar  bankAng_; 

//-  Rotor  pitch  angle 
scalar  pitchAng_; 

//-  Transof rmation  from  Carteisan  to  Pitch/Bank  plane 
tensor  PB_; 

//-  Transformation  from  Pitch  Bank  plane  to  Cartesian 
tensor  invPB_; 


//  Protected  Member  Functions 

//-  Check  data 
void  checkDataO; 

//-  Set  the  face  areas  per  cell,  and  optionally  correct  the  rotor  axis 
void  setFaceArea  (vectorSc  axis,  const  bool  correct); 

//-  Create  the  co-ordinate  system 
void  createCoordinateSystem ( ) ; 

//-  Construct  geometry 
void  constructGeometry ( ) ; 
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//-  Return  the  inlet  flow-field 

tmp<vectorField>  inf lowVelocity (const  volVectorFieldSc  U)  const; 

//-  Helper  function  to  write  rotor  values 
template<class  Type> 
void  writeField 
( 

const  wordS:  name, 
const  List<Type>&:  values, 
const  bool  writeNow  =  false 
)  const; 


public : 

//-  Runtime  type  information 
TypeName ( " rotorDisk" ) ; 


//  Constructors 


//-  Construct  from  components 
rotorDiskSource 
( 

const  wordS:  name, 
const  wordS:  modelType, 
const  dictionaryS:  diet, 
const  fvMeshS:  mesh 

)  ; 


//-  Destructor 

virtual  -rotorDiskSource (); 


//  Member  Functions 
//  Access 

//-  Return  the  cell  centre  positions  in  local  rotor  frame 

//  (Cylindrical  r,  theta,  z) 

inline  const  List<point>&:  x()  const; 

//-  Return  the  rotor  co-ordinate  system  (r,  theta,  z) 
inline  const  cylindricalCSS:  coordSys  ( )  const; 

//-  Return  rhoName_ 

inline  const  wordSc  getRhoName  ( )  const; 

//-  Return  rhoRef__ 

inline  const  scalarSc  getRhoRefO  const; 


//  Evaluation 

//-  Calculate  forces 
void  calculate 
( 

const  vectorFieldS:  U, 
const  scalarFieldSc  alphag, 
vectorFieldS:  force, 
const  bool  divideVolume  =  true, 
const  bool  output  =  true 
)  const; 

//  Source  term  addition 

//-  Source  term  to  fvMatrix<vector> 

virtual  void  addSup  ( fvMatrix<vector>&:  eqn,  const  label  fieldl); 


//  i-o 

//-  Write  the  source  properties 
virtual  void  writeData  (OstreamS:)  const; 

//-  Read  source  dictionary 

virtual  bool  read(const  dictionaryS:  diet); 
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//*************************************// 

}  //  End  namespace  Foam 

//*************************************// 

#include  "rotorDiskSourcel .H" 

//*************************************// 

#ifdef  NoRepository 

#include  "rotorDiskSourceTemplates . C" 

#endif 

//*************************************// 

#endif 

I j  *************************************************************************  j j 
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A.2.2  rotorDiskSource.C 


/* 


*\ 


\\  / 
\\  / 
\\  / 
\\/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011-2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 

You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* 


*/ 


#include 

#include 

#include 

#include 

#include 

#include 

#include 


" rotorDiskSource . H" 

" addToRunTimeSelectionTable . H" 
"mathematicalConstants . H" 

" trimModel . H" 

" unitConversion . H" 

" fvMatrices . H" 

" syncTools .  H" 


using  namespace  Foam: : constant ; 

//*************  static  Member  Functions  ************  // 


namespace  Foam 
{ 


defineTypeNameAndDebug (rotorDiskSource,  0) ; 

addToRunTimeSelectionTable (basicSource ,  rotorDiskSource,  dictionary) 

templateo  const  char*  NamedEnum<rotorDiskSource : : geometryModeType , 
names  []  = 

{ 

"auto" , 

" specified" 

}; 


2>:  : 


const  NamedEnum<rotorDiskSource :: geometryModeType ,  2> 
rotorDiskSource : : geometryModeTypeNames_; 

templateo  const  char*  NamedEnum<rotorDiskSource : : inletFlowType ,  3>:: 
names  []  = 

{ 

"fixed" , 

" surf aceNormal " , 

" local " 

}; 


const  NamedEnum<rotorDiskSource :: inletFlowType ,  3> 
rotorDiskSource: : inletFlowTypeNames  ; 

} 


//************  Protected  Member  Functions  ***********// 

void  Foam: : rotorDiskSource : :checkData() 

{ 

//  set  inflow  type 
switch  ( selectionMode ( ) ) 

{ 

case  smCellSet: 
case  smCellZone: 
case  smAll : 
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//  set  the  profile  ID  for  each  blade  section 

prof iles_. connectBlades (blade_.prof ileName ( ) ,  blade_.prof ilelD ( ) ) 
switch  (inletFlow  ) 

{ 

case  ifFixed: 

{ 

coeffs_. lookup (" inletVelocity" )  >>  inletVelocity_; 
break; 

} 

case  if Surf aceNormal : 


{ 

scalar  Uln 

( 

readScalar (coef f s_. lookup ( " inletNormalVelocity" )  ) 

)  ; 

inletVelocity_  =  -coordSys_. e3 ( ) *UIn; 
break; 

} 

case  ifLocal: 

{ 

//  do  nothing 
break; 

} 

default : 


{ 

} 


FatalErrorIn ( "void  rotorDiskSource : : checkData ( ) " ) 

<<  "Unknown  inlet  velocity  type"  <<  abort (FatalError) 


break; 


default : 

{ 

FatalErrorIn ( "void  rotorDiskSource : : checkData ( )  " ) 
<<  "Source  cannot  be  used  with  ' " 

<<  selection]yiodeTypeNames_  [selectionMode  ( )  ] 

<<  "'  mode.  Please  use  one  of:  "  <<  nl 
<<  selection]yiodeTypeNames_  [smCellSet]  <<  nl 


select ionModeTypeNames_ [smCellZone] 
selectionModeTypeNames_ [smAll] 
exit (FatalError) ; 


nl 


void  Foam :: rotorDiskSource :: setFaceArea (vectorSc  axis,  const  bool  correct) 

{ 

area_  =  0.0; 

static  const  scalar  tol  =  0.8; 

const  label  nInternalFaces  =  mesh_.nInternalFaces ( ) ; 
const  polyBoundaryMeshS:  pbm  =  mesh_.boundary]yiesh  ( )  ; 
const  vectorFieldS:  Sf  =  mesh_.Sf(); 
const  scalarFieldSc  magSf  =  mesh_.magSf  ( )  ; 

vector  n  =  vector :: zero ; 

//  calculate  cell  addressing  for  selected  cells 
labelList  cellAddr (mesh_.nCells ( ) ,  -1) ; 

UIndirectList<label> (cellAddr ,  cells_)  =  identity (cells_. size ()) ; 
labelList  nbrFaceCellAddr (mesh_. nFaces ( )  -  nInternalFaces,  -1) ; 

//  add  internal  field  contributions 

for  (label  facel  =  0;  facel  <  nInternalFaces;  facel++) 

{ 

const  label  own  =  cellAddr [mesh_. faceOwner ( ) [facel]]; 
const  label  nbr  =  cellAddr [mesh_. faceNeighbour ( ) [facel]]; 

if  ((own  !=  -1)  ScSc  (nbr  ==  -1)) 

{ 

vector  nf  =  Sf [facel] /magSf [facel] ; 

if  ( (nf  &  axis)  >  tol) 

{ 

area_[own]  +=  magSf [facel] ; 
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n  +=  Sf  [facel]  ; 


else  if  ((own  ==  -1)  ScSc  (nbr  !=  -1)) 

{ 

vector  nf  =  Sf [facel] /magSf [facel] ; 

if  ((-nf  &  axis)  >  tol) 

{ 

area_[nbr]  +=  magSf [facel] ; 
n  -=  Sf  [facel]  ; 


forAll (pbm,  patchl) 

{ 

const  polyPatchS:  pp  =  pbm  [patchl]  ; 

if  (pp . coupled ( ) ) 

{ 

forAll (pp,  i) 

{ 

label  facel  =  pp. start ()  +  i; 
label  nbrFacel  =  facel  -  nInternalFaces ; 
label  own  =  mesh_. f aceOwner ( )  [facel]; 
nbrFaceCellAddr [nbrFacel]  =  cellAddr [own] ; 


//  correct  for  parallel  running 

syncTools: : swapBoundaryFaceList (mesh_,  nbrFaceCellAddr) ; 

//  add  boundary  contributions 
forAll (pbm,  patchl) 

{ 

const  polyPatchS:  pp  =  pbm  [patchl]  ; 

const  vectorFieldS:  Sfp  =  mesh_.  Sf  ( )  .boundaryField  ( )  [patchl]; 
const  scalarFieldS:  magSfp  =  mesh_.magSf  ()  .boundaryField  ( )  [patchl]; 

if  (pp . coupled ( ) ) 

{ 

forAll (pp,  j) 

{ 

const  label  facel  =  pp. start ()  +  j; 

const  label  own  =  cellAddr [mesh_. f aceOwner ( ) [facel]]; 
const  label  nbr  =  nbrFaceCellAddr [facel  -  nInternalFaces]; 
const  vector  nf  =  Sfp [ j ] /magSfp [ j ] ; 


if  ((own  !=  -1)  ScSc  (nbr  ==  -1)  &&  (  (nf  &  axis)  >  tol)) 

{ 

area_[own]  +=  magSfp  [j  ]; 
n  +=  Sfp  [  j ]  ; 


else 


forAll (pp,  j) 

{ 

const  label  facel  =  pp. start ()  +  j; 

const  label  own  =  cellAddr [mesh_. f aceOwner ( ) [facel]]; 
const  vector  nf  =  Sfp [j ] /magSfp [j]; 


if  ((own  !=  -1)  ScSc  (  (nf  &  axis)  >  tol)) 

{ 

area_[own]  +=  magSfp  [j]; 
n  +=  Sfp  [j  ]  ; 


if  (correct) 

{ 

reduce (n,  sumOp<vector> ( ) ) ; 
axis  =  n/mag(n) ; 
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void  Foam: : rotorDiskSource : : createCoordinateSystem ( ) 

{ 

//  construct  the  local  rotor  co-prdinate  system 
vector  origin (vector :: zero) ; 
vector  axis (vector :: zero) ; 
vector  refDir (vector :: zero) ; 

geometryModeType  gm  = 

geometry]yiodeTypeNames_.  read  (coef  f  s_.  lookup  ( "geometryMode" )  )  ; 

switch  (gm) 

{ 

case  gmAuto: 

{ 

//  determine  rotation  origin  (cell  volume  weighted) 
scalar  sumV  =  0.0; 

const  scalarFieldS:  V  =  mesh_.V(); 
const  vectorFieldS:  C  =  mesh_.C(); 
forAll (cells  ,  i) 

{ 

const  label  celll  =  cells_[i]; 

sumV  +=  V [celll] ; 

origin  +=  V [celll] *C [celll]  ; 

} 

reduce (origin,  sumOp<vector> ( ) ) ; 
reduce(sumV,  sumOp<scalar> ( ) ) ; 
origin  /=  sumV; 

//  determine  first  radial  vector 
vector  dxl (vector :: zero) ; 
scalar  magR  =  -GREAT; 
forAll (cells  ,  i) 

{ 

const  label  celll  =  cells_[i]; 
vector  test  =  C [celll]  -  origin; 
if  (mag (test)  >  magR) 

{ 

dxl  =  test; 
magR  =  mag (test) ; 


reduce  (dxl,  max]yiagSqrOp<vector>  ( )  )  ; 
magR  =  mag (dxl) ; 

//  determine  second  radial  vector  and  cross  to  determine  axis 
forAll (cells  ,  i) 

{ 

const  label  celll  =  cells_[i]; 
vector  dx2  =  C  [celll]  -  origin; 
if  (mag(dx2)  >  0.5*magR) 

axis  =  dxl  ^  dx2 ; 
if  (mag (axis)  >  SMALL) 

{ 

break; 


reduce (axis,  maxMagSqrOp<vector> ( ) ) ; 
axis  /=  mag (axis) ; 

//  correct  the  axis  direction  using  a  point  above  the  rotor 

{ 

vector  pointAbove (coef fs_. lookup ( "pointAbove" ) ) ; 
vector  dir  =  pointAbove  -  origin; 
dir  /=  mag (dir) ; 
if  ((dir  Se.  axis)  <  0) 

{ 

axis  *=  - 1 . 0 ; 


coef fs_. lookup ( "refDirection" )  >>  refDir; 

//  set  the  face  areas  and  apply  correction  to  calculated  axis 
//  e.g.  if  cellZone  is  more  than  a  single  layer  in  thickness 
setFaceArea (axis ,  true); 
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break; 

} 

case  gmSpecified: 

{ 

coeffs_. lookup ( "origin" )  >>  origin; 

coeffs_. lookup ( "axis" )  >>  axis; 
coeffs_. lookup ( "refDirection" )  >>  refDir; 

setFaceArea (axis ,  false); 

break; 

} 

default : 

{ 

FatalErrorIn ( " rotorDiskSource : : createCoordinateSystem ( ) ") 

<<  "Unknown  geometryMode  "  <<  geometryModeTypeNames_ [gm] 
<<  " .  Available  geometry  modes  include  " 

<<  geometry]yiodeTypeNames_  <<  exit  (FatalError)  ; 


coordSys_  =  cylindricalCS ( " rotorCoordSys " ,  origin,  axis,  refDir,  false); 

//  BEWARE  WHEN  USING  THIS  cylindricalCS  CLASS.  IT  IS  INCOMPLETE! 

/*  //  ==========  THIS  METHOD  RETURNS  SEG  FAULT  ON  MRH90  CASE  =============  // 

//  Calculate  rotor  pitch  and  bank  angles  from  local  co-ordinate  system 

//  normalised  pitch-bank  plane  normal 

vector  nNPB  =  coordSys_. e3 ( ) /mag (coordSys_. e3 ( ) ) ; 

//  Projection  of  normal  onto  cartesian  Y-Z  plane 

vector  nPBYZ  =  vector (0,  coordSys_. e3 ( ) . y ( ) ,  coordSys_. e3 ( ) . z ( ) ) ; 
vector  nNPBYZ  =  nPBYZ/mag (nPBYZ ) ; 

//  Projection  of  normal  onto  cartesian  X-Z  plane 

vector  nPBXZ  =  vector (coordSys_. e3 () .x () ,  0,  coordSys_. e3 ( ) . z ( ) ) ; 
vector  nNPBXZ  =  nPBXZ/mag (nPBXZ ) ; 

//  Rotation  of  PB  plane  about  X  axis  (bank  angle) 

bankAng_  =  -acos(nNPB  &  nNPBYZ )* (coordSys_. e3 (). y () /mag (coordSys_. e3 (). y ())) ; 
//  Rotation  of  PB  plane  about  Y  axis  (pitch  angle) 

pitchAng_  =  acos (nNPB  &  nNPBXZ) * (coordSys_. e3 () .x () /mag (coordSys_. e3 () .x ())) ; 
*/  //  ========================================================================  // 

//  alternative  way  of  calculating  pitch  and  bank  angles 
bankAng_  =  atan2 (coordSys_. e3 ( )  . y ( )  ,  coordSys_. e3 ( )  . z  ( ) )  ; 
pitchAng_  =  atan2 (coordSys_. e3 ( ) .x ( ) ,  coordSys_. e3 ( ) . z ( ) ) ; 


//  Tensor  for  transforming  from  Cartesian  into  Pitch/Bank  Plane 

scalar  cp  =  cos (pitchAng_) ; 

scalar  sp  =  sin (pitchAng_) ; 

scalar  cb  =  cos (bankAng_) ; 

scalar  sb  =  sin (bankAng_) ; 

PB_  =  tensor(cp,  sp*sb,  sp*cb,  0,  cb,  -sb,  -sp,  cp*sb,  cp*cb) ; 


/* 

//  Alternative  way  of  constructing  the  rotational  tensor 

scalar  cp  =  cos (pitchAng_) ; 

scalar  sp  =  sin (pitchAng_) ; 

scalar  cb  =  cos ( -bankAng_) ; 

scalar  sb  =  sin ( -bankAng_) ; 

//  rotation  tensor  about  the  cartesian  X-Axis  by  bankAng_ 
tensor  bankRotate  =  tensord,  0,  0,  0,  cb,  sb,  0,  -sb,  cb)  ; 

//  rotation  tensor  about  the  cartesian  Y-axis  by  pitchAng_ 
tensor  pitchRotate  =  tensor(cp,  0,  -sp,  0,  1,  0,  sp,  0,  cp) ; 

//  combined  bank  and  pitch  rotations 
=  pitchRotate  *  bankRotate; 

II  manual  check  of  the  combined  rotational  tensor 

//PB_  =  tensor(cp,  -sp*sb,  -sp*cb,  0,  cb,  -sb,  sp,  cp*sb,  cp*cb) ; 


//  Tensor  for  transforming  from  Pitch/Bank  Plane  into  Cartesian 
invPB_  =  PB_. T ( ) ; 
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} 


const  scalar  sumArea  =  gSum(area_); 

const  scalar  diameter  =  Foam: : sqrt (4 . 0*sumArea/mathematical : :pi) ; 
Info<<  "  ===================================  "  <<  nl 

<<  "  #  Using  rotorDiskSource  20120822  #  "  <<  nl 

<<  "  ===================================  "  <<  nl  <<  endl; 


Info<< 
<< 
<  < 
<  < 
<< 
<  < 
<  < 
<< 
<  < 


Rotor  gometry: "  <<  nl 


-  disk  diameter  =  "  << 

-  disk  area  =  "  << 

-  origin  =  "  << 

-  r-axis  =  "  << 

-  psi-axis  =  "  << 

-  z-axis  =  "  << 

-  disk  pitch  angle  =  "  << 

-  disk  bank  angle  =  "  << 


diameter  <<  nl 
sumArea  <<  nl 
coordSys_. origin ( )  <<  nl 
coordSys_. el ( )  <<  nl 
coordSys_. e2 ( )  <<  nl 
coordSys_. e3 ( )  <<  nl 
pitchAng_  <<  nl 
bankAng_  <<  endl; 


void  Foam: : rotorDiskSource : : constructGeometry ( ) 

{ 

const  vectorFieldS:  C  =  mesh_.C(); 

forAll (cells  ,  i) 

{ 

if  (area  [i]  >  ROOTVSMALL) 

{ 

const  label  celll  =  cells_[i]; 

//  position  in  (planar)  rotor  co-ordinate  system 
x_[i]  =  coordSys_. localPosition (C [celll] ) ; 

//  cache  max  radius 

rMax__  =  max(r]yiax_,  x_[i]  .x()  )  ; 

//  swept  angle  relative  to  rDir  axis  [radians]  in  range  0  ->  2*pi 
scalar  psi  =  x_[i]  .y()  ; 

if  (rotorDebug  ) 

{ 

psiList  [i]  =  radToDeg (psi ) ; 

} 


//  blade  flap  angle  [radians] 
scalar  beta  = 

flap_.betaO  -  f lap_.betal*cos (psi)  -  f lap_.beta2*sin (psi) ; 

//  determine  rotation  tensor  to  convert  from  planar  system  into  the 
//  rotor  cone  system 
scalar  c  =  cos (beta) ; 
scalar  s  =  sin (beta) ; 

R__[i]  =  tensor(c,  0,  -s,  0,  1,  0,  s,  0,  c)  ; 
invR_[i]  =  R_[i]  .TO  ; 


//  reduce  rMax_  for  parallel  running 
reduce (rMax  ,  maxOp<scalar> ( ) ) ; 

} 


Foam: :tmp<Foam: : vectorField>  Foam: : rotorDiskSource : : inf lowVelocity 

( 

const  volVectorFieldSc  U 
)  const 
{ 

switch  (inletFlow  ) 

{ 

case  ifFixed: 

case  if Surf aceNormal : 

{ 

return  tmp<vectorField> 

( 

new  vectorField (mesh_. nCells ( ) ,  inletVelocity_) 

)  ; 

break; 

} 

case  if Local : 

{ 

return  U. internalField ( ) ; 
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break; 

} 

default : 

{ 

FatalErrorIn 

( 

"Foam: :tmp<Foam: : vectorField>  " 

"Foam: : rotorDiskSource : : inf lowVelocity" 

"  (const  volVectorFieldS:)  const" 

)  <<  "Unknown  inlet  flow  specification"  <<  abort (FatalError) ; 

} 

} 

return  tmp<vectorField> (new  vectorField (mesh  .nCellsO,  vector :: zero) ) ; 

} 


//***************  Constructors  ***************// 

Foam: : rotorDiskSource : : rotorDiskSource 

( 

const  wordS:  name, 
const  wordS:  modelType, 
const  dictionary’s:  diet, 
const  fvMeshS:  mesh 


) 

basicSource (name ,  modelType,  diet,  mesh), 

rhoName_ ( " none " ) , 

rhoRef_ (1.2) , 

rotorDebug_(false) , 

omega_ (0.0) , 

nBlades_ ( 0 ) , 

inletFlow_ ( if Local )  , 

inletVelocity_ (vector : :zero) , 

tipEf f ect_ ( 1 . 0 ) , 

flap_()  , 

x_ (cells_. size ( ) ,  vector: :zero) , 

R_ (cells_. size ( ) ,  I), 
invR_ (cells_. size ( ) ,  I), 
area_ (cells_. size ( )  ,  0.0), 
coordSys_(false) , 
rMax_ (0.0) , 

psiList_ (cells_. size ( ) ,  0.0), 
trim_ (trimModel : :New(*this,  coeffs_) ) , 
blade_ (coef f s_. subDict ( "blade" ) ) , 
profiles  (coeffs  . subDict ( "prof iles ") ) 

{ 

read (diet ) ; 

} 


//****************  Destructor  ***************// 

Foam: : rotorDiskSource : : -rotorDiskSource ( ) 

{} 


//***************  Member  Functions  *************// 

void  Foam: : rotorDiskSource : : calculate 

( 

const  vectorFieldS:  U, 
const  scalarFieldS:  alphag, 
vectorFieldS:  force, 
const  bool  divideVolume , 
const  bool  output 
)  const 
{ 

const  vectorFieldS:  C  =  mesh_.C(); 
const  scalarFieldS:  V  =  mesh_.V(); 
const  bool  compressible  =  rhoName_  !=  "none"; 

tmp<volScalarField>  trho 

( 

compressible 

?  mesh_. lookupObj ect<volScalarField> (rhoName_) 

:  volScalarField : : null ( ) 

)  ; 
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//  logging  info 
scalar  dragEff  =  0.0; 
scalar  liftEff  =  0.0; 
scalar  AOAmin  =  GREAT; 
scalar  AOAmax  =  -GREAT; 
scalar  epsMin  =  GREAT; 
scalar  epsMax  =  -GREAT; 
scalar  CdMin  =  10.0; 
scalar  CdMax  =  VSMALL; 
scalar  ClMin  =  10.0; 
scalar  ClMax  =  VSMALL; 

scalar  totalThrust  =  0.0; 
scalar  totalPitchingMoment  =  0.0; 
scalar  totalRollingMoment  =  0.0; 


//  begin  looping  over  all  rotor  cells 
forAll (cells_,  i) 

{ 

if  (area  [i]  >  ROOTVSMALL) 

{ 

const  label  celll  =  cells_[i]; 

const  scalar  radius  =  x_[i] .x() ; 
const  scalar  psi  =  x_[i]  .y()  ; 

//  velocity  in  local  cylindrical  reference  frame 

//  the  localVector  function  below  is  just  for  position  vector. 

//vector  Uc  =  coordSys_. localVector (U [celll] ) ; 

II  velocity  in  local  cylindrical  reference  frame 

//  This  assumes  that  the  Uz  is  the  same  as  the  rotorDiskPlane  normal  axis. 

//  aligning  U  to  the  pitch  bank  angle  plane 
vector  Upb  =  PB_  &  U [celll] ; 


/* 


*/ 


vector  Uc  =  vector 

( 

Upb .X ( ) *cos (psi) +Upb .y ( )* sin (psi) , 

-Upb .X  0  * sin (psi) +Upb .y ( )* cos (psi) , 

Upb . z  ( ) 

)  ; 

//  transforming  velocity  to  rotor  local  cylindrical  frame 

//  using  the  dot  products  of  the  two  systems'  base  vectors 

const  vector  elGlobal  =  vector  (1,  0,  0) ; 

const  vector  e2Global  =  vector  (0,  1,  0) ; 

const  vector  e3Global  =  vector  (0,  0,  1) ; 

vector  Uc  =  vector  (0,  0,  0)  ; 

Uc.xO  =  U  [celll]  .x()  *  (coordSys_.  el  ( )  &  elGlobal)  + 

U[celll] .yO  *  (coordSys_. e2 ( )  &  elGlobal)  + 

U[celll].z()  *  (coordSys_. e3 ( )  &  elGlobal); 

Uc.yO  =  U[celll]  .x()  *  (coordSys_.  el  ( )  &  e2Global)  + 

U[celll] .y()  *  (coordSys_. e2 ( )  &  e2Global)  + 

U[celll].z()  *  (coordSys_. e3 ( )  &  e2Global); 

Uc  . z  ( )  =  U [celll]  .x()  *  (coordSys_. el ( )  &  e3Global)  + 

U[celll] .y()  *  (coordSys_. e2 ( )  &  e3Global)  + 

U[celll].z()  *  (coordSys_. e3 ( )  &  e3Global) ; 

//  ==>  This  method  does  not  work  because  the  coordSys_. el ( ) ,  e2 ( ) 

//  and  e3 ( )  does  not  return  the  base  vectors  of  r,  psi,  z  in  terms  of 
//  i,  j,  k  for  each  cell.  In  fact  only  e3()  vector  is  correct. 

//  el()  and  e2 ( )  were  found  to  not  vary  with  cell  position. 


//  transform  from  rotor  cylindrical  into  local  coning  system 
Uc  =  R_[i]  &  Uc; 

//  set  radial  component  of  velocity  to  zero 
Uc . X ( )  =  0.0; 

//  total  Utheta 

//scalar  Ut  =  radius*omega_  +  Uc.yO; 

//  set  blade  normal  component  of  velocity 
Uc.yO  =  radius*omega_  -  Uc.yO; 
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//  air  angle 
//scalar  eps 
scalar  eps  = 


(rad) 

=  atan2 (Uc . z ( ) ,  f abs (Ut ) ) ; 
atan2 ( -Uc . z ( ) ,  Uc . y ( ) ) ; 


if 

{ 

} 

if 

{ 

} 


(eps  <  -mathematical :: pi ) 
eps  =  (2 . 0*mathematical : :pi  +  eps) ; 
(eps  >  mathematical :: pi ) 
eps  =  (eps  -  2 . 0*mathematical : :pi) ; 


epsMin  =  min (epsMin,  eps) ; 
epsMax  =  max (epsMax,  eps) ; 

//  determine  blade  data  for  this  radius 

//  i2  =  index  of  upper  radius  bound  data  point  in  blade  list 

scalar  twist  =  0.0; 

scalar  chord  =  0.0; 

label  il  =  -1; 

label  i2  =  -1; 

scalar  invDr  =  0.0; 

blade_. interpolate (radius ,  twist,  chord,  il,  i2,  invDr) ; 

//  flip  geometric  angle  if  blade  is  spinning  in  reverse  (clockwise) 
scalar  alphaGeom  =  alphag[i]  +  twist; 
if  (omega_  <  0) 

{ 

alphaGeom  =  mathematical :: pi  -  alphaGeom; 

} 

//  effective  angle  of  attack 

scalar  alphaEff  =  alphaGeom  -  atan2 ( -Uc . z ( ) ,  Uc.yO); 


if 

{ 

} 

if 

{ 

} 


(alphaEff 

alphaEff 

(alphaEff 

alphaEff 


<  -mathematical :: pi ) 

=  (2 . 0*mathematical : :pi  +  alphaEff); 
>  mathematical :: pi ) 

=  (alphaEff  -  2 . 0*mathematical : :pi) ; 


AOAmin  =  min(AOAmin,  alphaEff); 

AOAmax  =  max(AOAmax,  alphaEff); 

//  determine  profile  data  for  this  radius  and  angle  of  attack 
const  label  profilel  =  blade_.prof ilelD ( ) [il] ; 
const  label  profile2  =  blade_.prof ilelD ( ) [i2] ; 

scalar  Cdl  =  0.0; 
scalar  Cll  =  0.0; 

prof iles_ [prof ilel] . Cdl (alphaEff ,  Cdl,  Cll) ; 

scalar  Cd2  =  0.0; 
scalar  C12  =  0.0; 

prof iles_ [prof ile2] . Cdl (alphaEff ,  Cd2 ,  C12); 

scalar  Cd  =  invDr* (Cd2  -  Cdl)  +  Cdl; 
scalar  Cl  =  invDr* (C12  -  Cll)  +  Cll; 

CdMin  =  min(CdMin,  fabs(Cd)); 

CdMax  =  max(CdMax,  fabs(Cd)); 

ClMin  =  min(ClMin,  fabs(Cl)); 

ClMax  =  max(ClMax,  fabs(Cl)); 

//  apply  tip  effect  for  blade  lift 

scalar  tipFactor  =  1.0; 

if  ( ( radius /rMax  )  >  tipEffect  ) 

{ 

tipFactor  =  0.0; 

} 


//scalar  tipFactor  =  neg (radius /rMax_  -  tipEffect_) ; 

//  calculate  forces  perpendicular  to  blade 
scalar  pDyn  =  0 . 5*magSqr (Uc ) ; 
if  (compressible) 
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{ 

pDyn  *=  trhoO  [celll]  ; 

} 


scalar  f  =  pDyn*chord*nBlades_*area_ [i] /radius/mathematical : : twoPi ; 
//  forces  in  blade  coordinate  system 

//scalar  ftc  =  (f *Cd*cos (eps)  -  tipFactor*f *Cl*sin (eps) ) ; 

//scalar  fnc  =  (f *Cd*sin (eps)  +  tipFactor*f *Cl*cos (eps) ) ; 

//  Implementation  of  Kim  et  al  [7th  OpenFOAM  Workshop] 
scalar  ftc  =  (f *Cd*cos (eps)  +  tipFactor*f *Cl*sin (eps) ) ; 
scalar  fnc  =  ( - f *Cd*sin (eps )  +  tipFactor*f *Cl*cos (eps) ) ; 

//vector  localForce  =  vector(0.0,  -f*Cd,  tipFactor*f*Cl) ; 
vector  localForce  =  vector(0.0,  -ftc,  fnc) ; 


if  (compressible) 

{ 

//  accumulate  forces 
dragEff  +=  localForce . y () ; 
liftEff  +=  localForce . z 0 ; 

} 

else 


dragEff 

liftEff 


rhoRef_*localForce . y ( )  ; 
rhoRef_*localForce . z ( ) ; 


if  (rotorDebug  ) 

{ 

if  (i  ==  0) 

{ 

Info  <<  "Celll  psi  radius  alphaEff  " 

<<  "eps  Cl  Cd  f  fn  fth"  <<  nl  <<  endl; 

} 

Info  <<  celll  <<  "  "  <<  psiList_ [celll]  <<  "  "  <<  radius  << 

<<  radToDeg (alphaEff )  <<  "  " 

<<  radToDeg (eps)  <<  "  " 

<<  Cl  <<  "  "  <<  Cd  <<  "  " 

<<  f  <<  "  "  <<  localForce . y ( )  <<  "  "  <<  localForce . z ( ) 

<<  endl; 

} 


//  convert  force  from  local  coning  system  into  rotor  cylindrical 
localForce  =  invR__[i]  &  localForce; 

//  convert  force  to  global  cartesian  co-ordinate  system 
//  similarly  to  the  localVector  function,  the  globalVector  is 
//  only  meant  for  the  position  vector. 

//force [celll]  =  coordSys_. globalVector ( localForce) ; 

//  convert  force  to  global  cartesian  co-ordinate  system 

//  the  line  below  assumes  that  there  is  zero  tilt  on  the  rotorDiskPlane 
localForce  =  vector 
( 

localForce . X 0 *cos (psi )  -  localForce .y () *sin (psi) , 
localForce .X 0 *sin (psi)  +  localForce . y () *cos (psi ) , 
localForce . z ( ) 

)  ; 

force [celll]  =  invPB_  &  localForce; 


//  transforming  force  from  rotor  local  cylindrical  to  global  cartesian 
//  using  the  dot  products  of  the  two  systems'  base  vectors 


vector  globalForce 

:  =  vector  (0, 

0 , 

0)  ; 

globalForce . X ( )  = 

localForce . x ( ) 

•k 

(coordSys 

■  elO 

& 

elGlobal ) 

+ 

localForce • y ( ) 

•k 

(coordSys 

.e2  0 

& 

elGlobal ) 

+ 

localForce . z ( ) 

k 

(coordSys 

.e3  0 

& 

elGlobal) 

globalForce . y ( )  = 

localForce . x ( ) 

k 

(coordSys 

■  elO 

& 

e2Global ) 

+ 

localForce . y ( ) 

k 

(coordSys 

.e2  0 

& 

e2Global ) 

+ 

localForce . z ( ) 

k 

(coordSys_. 

.e3  {) 

& 

e2Global) 

globalForce . z ( )  = 

localForce . x ( ) 

k 

(coordSys 

■  elO 

& 

eSGlobal ) 

+ 

localForce . y ( ) 

k 

(coordSys 

.e2  {) 

& 

eSGlobal ) 

+ 

localForce . z ( ) 

★ 

(coordSys 

.e3  0 

& 

eSGlobal) 
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force [celll]  =  globalForce; 

//  ==>  This  method  does  not  work  because  the  coordSys_. el ( ) ,  e2 ( ) 

//  and  e3 ( )  does  not  return  the  base  vectors  of  r,  psi,  z  in  terms  of 
//  i,  j,  k  for  each  cell.  In  fact  only  e3()  vector  is  correct. 

//  el()  and  e2()  were  found  to  not  vary  with  cell  position. 


if  (compressible) 

{ 

//  calculate  global  thrust  and  moment 

vector  moment  =  force [celll] ^ (C [celll]  -  coordSys_. origin ()) ; 
totalThrust  +=  force [celll]  &  coordSys_. e3 ( ) ; 
totalPitchingMoment  +=  moment  &.  coordSys_.  e2  ( )  ; 
totalRollingMoment  +=  moment  &  coordSys  .el(); 

} 

else 

vector  moment  =  force  [celll]  (C  [celll]  -  coordSys_.  origin  ())  ; 
totalThrust  +=  (rhoRef_  *  (force [celll]  &  coordSys_. e3 ( ) ) ) ; 
totalPitchingMoment  +=  (rhoRef_  *  (moment  &  coordSys_. e2 ( ) ) ) ; 
totalRollingMoment  +=  (rhoRef  *  (moment  &.  coordSys  .el())); 

} 

if  (divideVolume ) 

{  //  calculate  momentum  source 

force[cellI]  /=  V[celll]; 

} 


if  (output) 


reduce (AOAmin,  minOp<scalar> ( ) ) ; 

reduce (AOAmax,  maxOp<scalar> ( ) ) ; 

reduce (epsMin,  minOp<scalar> ( ) ) ; 

reduce (epsMax,  maxOp<scalar> ( ) ) ; 

reduce (dragEff ,  sumOp<scalar> ( ) ) ; 

reduce ( lif tEf f ,  sumOp< scalar > ( ) ) ; 

reduce (totalThrust ,  sumOp<scalar> ( ) ) ; 

reduce (totalPitchingMoment ,  sumOp<scalar> ( ) ) 

reduce (totalRollingMoment ,  sumOp<scalar> ( ) ) ; 


} 


Info<< 
<< 
<  < 
<  < 
<< 
<< 
<  < 
<< 
<< 
<  < 


type ( )  <<  "  output:"  <<  nl 
"  min/max(AOA)  =  "  << 

radToDeg (AOAmax)  <<  nl 
"  min/max ( induced  AOA) 

radToDeg (epsMax)  <<  nl 
"  Effective  blade  drag 

"  Effective  blade  lift 

"  Total  Thrust 

"  Total  Pitching  Moment 

"  Total  Rolling  Moment 


radToDeg (AOAmin)  <<  ",  " 

=  "  <<  radToDeg (epsMin)  <<  ",  " 

=  "  <<  dragEff  <<  nl 
=  "  <<  liftEff  <<  nl 
=  "  <<  totalThrust  <<  nl 
=  "  <<  totalPitchingMoment  <<  nl 
=  "  <<  totalRollingMoment  <<  endl; 


void  Foam : : rotorDiskSource : : addSup ( fvMatrix<vector>&:  eqn,  const  label  fieldl) 

{ 

dimensionSet  dims  =  dimless; 
if  (eqn . dimensions ( )  ==  dimForce) 

{ 

coeffs_. lookup ( "rhoName" )  >>  rhoName_; 

dims . reset (dimForce/dimVolume ) ; 

} 

else 

{ 

coeffs_. lookup ( "rhoRef" )  >>  rhoRef_; 

dims . reset (dimForce/dimVolume/dimDensity) ; 

} 


volVectorField  force 

( 

lOobj  ect 

( 


" rotorForce " , 

mesh_. time ( ) . timeName ( ) , 

mesh_, 

lOobject: :NO_READ, 
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lOobject: :NO_WRITE 

)  , 

mesh_, 

dimensionedVector { " zero" ,  dims,  vector :: zero) 

)  ; 

const  volVectorFieldS:  U  =  eqn.psiO; 

const  vectorField  Uin  =  inf lowVelocity (U) ; 

trim_- >correct (Uin,  force); 

calculate (Uin,  trim_- >alphag { ) ,  force); 

//  add  source  to  rhs  of  eqn 
eqn  +=  -force; 

if  (mesh  . time ( ) . outputTime ( ) ) 

{ 

force . write ( ) ; 


void  Foam :  :  rotorDiskSource  :  :  writeData  (OstreamS:  os)  const 

{ 

os  <<  indent  <<  name_  <<  endl; 
diet  .write (os); 

} 


bool  Foam:  :  rotorDiskSource ::  read  (const  dictionary’s:  diet) 

{ 

if  (basicSource :: read (diet ) ) 

{ 

coeffs_. lookup (" fieldNames " )  >>  fieldNames_; 
applied_. setSize (f ieldNames_. size ( ) ,  false) ; 

//  read  if  rotorDebug  is  active 

coeffs_. lookup ( "rotorDebugMode" )  >>  rotorDebug_; 

//  read  co-ordinate  system/geometry  invariant  properties 
scalar  rpm (readScalar (coeffs_. lookup (" rpm" ) ) ) ; 
omega_  =  rpm/60.0*mathematical::twoPi; 

coeffs_. lookup ( "nBlades" )  >>  nBlades_; 

inletFlow_  =  inletFlowTypeNames_. read (coeffs_. lookup (" inletFlowType" ) ) 
coeffs_. lookup ( "tipEf feet" )  >>  tipEffect_; 

const  dictionaryS:  flapCoeffs(coeffs_.subDict("flapCoeffs")); 

f lapCoeffs . lookup ( "betaO " )  >>  flap_.betaO; 

f lapCoeffs . lookup ( "betal " )  >>  flap_.betal; 

f lapCoeffs . lookup ( "beta2 " )  >>  flap_.beta2; 

flap_.betaO  =  degToRad ( f lap_. betaO ) ; 

flap_. betal  =  degToRad (flap_. betal) ; 

flap_.beta2  =  degToRad (flap_.beta2); 


//  create  co-ordinate  system 
createCoordinateSystem ( ) ; 

//  read  co-odinate  system  dependent  properties 
checkData ( ) ; 

constructGeometry ( ) ; 

//  reading  rhoName_ 

coeffs_. lookup ( "rhoName" )  >>  rhoName_; 

coeffs_. lookup ( "rhoRef" )  >>  rhoRef_; 

trim_- >read (coef f  s_)  ; 

if  (debug) 

{ 

writeField ( " alphag" ,  trim_- >alphag ( ) (),  true); 
writeField ( " f aceArea" ,  area  ,  true); 

} 
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return  true; 


else 


return  false; 


// 


// 
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A.2.3  rotorDiskSourceTemplates.C 


/* 


*\ 


\\  / 
\\  / 
\\  / 
\\/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  " rotorDiskSource . H" 

#include  "volFields . H" 

//************  Protected  Member  Functions  ***********  // 
template<class  Type> 

void  Foam: : rotorDiskSource : :writeField 

{ 

const  wordS:  name, 
const  List<Type>&:  values, 
const  bool  writeNow 
)  const 
{ 

typedef  GeometricField<Type ,  fvPatchField,  volMesh>  fieldType; 

if  (mesh_. time ( ) . outputTime ( )  | |  writeNow) 

tmp<f ieldType>  tfld 

( 

new  fieldType 

( 

lOobj  ect 

( 

name , 

mesh_. time ( ) . timeName ( ) , 
mesh_, 

lOobject: :N0_READ, 
lOobject: :N0_WRITE 

)  , 

mesh_, 

dimensioned<Type> { " zero" ,  dimless,  pTraits<Type> : : zero) 

) 

)  ; 

Field<Type>&:  fid  =  tf  Id  ( )  .  internalField  ( )  ; 

if  (cells  .sizeO  !=  values  .  size  ()  ) 

{ 

FatalErrorIn ( " " )  <<  "cells_. size ( )  !=  values_. size ( ) " 

<<  abort (FatalError) ; 

} 


forAll (cells  ,  i) 

{ 

const  label  celll  =  cells_[i]; 
fld[celll]  =  values [i] ; 

} 


tfld  ( )  .write  ( )  ; 


// 


************************************************************************* 


// 


128 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-TR-2931 


A.2.4  rotorDiskSourcel.H 


/* 


*\ 


W  / 
W  / 
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F  ield 
O  peration 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  " rotorDiskSource . H" 

const  Foam:  :List<Foam:  :point>&:  Foam ::  rotorDiskSource  :: x  ( )  const 

{ 

return  x  ; 

} 


const  Foam : : cylindricalCSS:  Foam :: rotorDiskSource :: coordSys ( )  const 

{ 

return  coordSys  ; 

} 


const  Foam:  :word&:  Foam ::  rotorDiskSource  ::  getRhoName  ( )  const 

{ 

return  rhoName  ; 

} 


const  Foam :  :  scalarS:  Foam ::  rotorDiskSource  ::  getRhoRef  ( )  const 

{ 

return  rhoRef  ; 

} 


j j  *************************************************************************  j j 
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A.2.5  bladeModel.H 


/* 


*\ 


\\  / 
\\  / 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: :bladeModel 


Description 

Blade  model  class 


SourceFiles 

bladeModel . C 


\* - */ 

#ifndef  bladeModel_H 
#define  bladeModel_H 

#include  "List.H" 

#include  "dictionary . H" 

//*************************************// 

namespace  Foam 

{ 

/* 

\* 

class  bladeModel 

{ 

protected : 

//  Protected  data 

//-  Corresponding  profile  name  per  section 
List<word>  prof ileName_; 

//-  Corresponding  profile  ID  per  section 
List<label>  profileID_; 

// -  Radius  [m] 

List<scalar>  radius_; 

//-  Twist  [deg]  on  input,  converted  to  [rad] 

List<scalar>  twist_; 

//-  Chord  [m] 

List<scalar>  chord_; 

//-  File  name  (optional) 
fileName  fName_; 


//  Protected  Member  Functions 


- *\ 

Class  bladeModel  Declaration 
- */ 
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//-  Return  ture  if  file  name  is  set 
bool  readFromFile ( )  const; 

//-  Return  the  interpolation  indices  and  gradient 
void  interpolateWeights 
( 

const  scalarS:  xin, 
const  List<scalar>&:  values, 
labelSc  il, 
labels  i2, 
scalarS:  ddx 
)  const; 


public : 

//-  Constructor 

bladeModel  (const  dictionary’s:  diet)  ; 


//-  Destructor 
virtual  -bladeModel (); 


//  Member  functions 
1 1  Access 

//-  Return  const  access  to  the  profile  name  list 
const  List<word>S:  prof  ileName  ( )  const; 

//-  Return  const  access  to  the  profile  ID  list 
const  List<label>S:  profilelDO  const; 

//-  Return  const  access  to  the  radius  list 
const  List<scalar>S:  radius  ( )  const; 

//-  Return  const  access  to  the  twist  list 
const  List<scalar>&:  twist  ()  const; 

//-  Return  const  access  to  the  chord  list 
const  List<scalar>&:  chord  ( )  const; 


//  Edit 

//-  Return  non-const  access  to  the  profile  ID  list 
List<label>&:  profilelDO; 


//  Evaluation 

//-  Return  the  twist  and  chord  for  a  given  radius 
virtual  void  interpolate 

( 

const  scalar  radius, 
scalarS:  twist, 
scalarS:  chord, 
labelSc  il, 
labels:  i2, 
scalarS:  invDr 
)  const; 

}; 


//*************************************// 
}  //  End  namespace  Foam 

//*************************************// 

#endif 

j j  *************************************************************************  j j 
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A.2.6  bladeModel.C 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011-2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* 


#include 

#include 

#include 

#include 

#include 


"bladeModel . H" 
"unitConversion . H" 
"Tuple2 .H" 

"vector . H" 
"IFstream.H" 


*/ 


//*************  Protected  Member  Functions  **********  // 

bool  Foam :: bladeModel :: readFromFile { )  const 

{ 

return  fName  !=  f ileName : : null ; 

} 


void  Foam: :bladeModel: : interpolateWeights 

{ 

const  scalarS:  xin, 
const  List<scalar>&:  values, 
labels  il, 
labels  i2, 
scalarSc  ddx 
)  const 
{ 

i2  =  0; 

label  nElem  =  values . size () ; 

if  (nElem  ==  1) 

{ 

il  =  i2; 
ddx  =  0.0; 
return; 

} 

else 

{ 

while  ( (values [i2]  <  xIn)  &&  (i2  <  nElem)) 

{ 

i  2  +  +  ; 

} 

if  (i2  ==  nElem) 

{ 

i2  =  nElem  -  1; 
il  =  i2; 
ddx  =  0.0; 
return; 

} 

else 

{ 

il  =  i2  -  1; 

ddx  =  (xin  -  values [il] ) / (values [i2]  -  values [il] ) ; 

} 
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//****************  Constructors  **************// 

Foam:  ibladeModel :  rbladeModel  (const  dictionary’s:  diet) 

prof ileName_ ( ) , 
prof ileID_ ( ) , 
radius_ ( ) , 
twist_ ( ) , 
chord_ ( ) , 

fName  ( f ileName : : null ) 

{ 

List<Tuple2<word,  vector>  >  data; 
if  (readFromFile ( ) ) 

{ 

IFstream  is(fName_); 
is  >>  data; 

} 

else 

{ 

diet . lookup ( "data" )  >>  data; 

} 


if  (data.sizeO  >  0) 

{ 

prof ileName_. setSize (data . size ( )  )  ; 
prof ileID_. setSize (data . size ( ) ) ; 
radius_. setSize (data . size ( ) ) ; 
twist_. setSize (data . size ( )  )  ; 
chord_. setSize (data . size ( ) ) ; 

f orAll (data ,  i ) 

{ 

prof ileName_ [i]  =  data [i] . first () ; 

prof ileID_ [i]  =  -1; 

radius_[i]  =  data [i] . second ( ) [0] ; 

twist_[i]  =  degToRad (data [i] . second ( ) [1] ) ; 

chord_[i]  =  data  [i]  .  second  ( )  [2]  ; 


else 

{ 

FatalErrorIn  ( " Foam :  : bladeModel :  :bladeModel  (const  dictionaryS:)  ") 
<<  "No  blade  data  specified"  <<  exit (FatalError) ; 


11  *****************  Destructor  **************// 

Foam: : bladeModel : : -bladeModel ( ) 

{} 


//************  Public  Member  Functions  ************  J  J 

const  Foam :  :  List<Foam :  :  word>S:  Foam ::  bladeModel ::  prof  ileName  ( )  const 

{ 

return  profileName  ; 

} 


const  Foam:  :List<Foam:  :  label>S:  Foam :: bladeModel :: prof  ilelD  ( )  const 

{ 

return  profilelD  ; 

} 


const  Foam :  :  List<Foam :  :  scalar>S:  Foam ::  bladeModel ::  radius  ( )  const 

{ 

return  radius  ; 

} 


const  Foam :  :  List<Foam :  :  scalar>&:  Foam ::  bladeModel ::  twist  ( )  const 

{ 

return  twist_; 
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} 


const  Foam :  :  List<Foam :  :  scalar>&:  Foam ::  bladeModel ::  chord  ( )  const 

{ 

return  chord  ; 

} 


Foam:  :List<Foam:  :label>&:  Foam:  :  bladeModel :  :profileID() 

{ 

return  profilelD  ; 

} 


void  Foam: :bladeModel: : interpolate 

{ 

const  scalar  radius, 
scalarS:  twist, 
scalarS:  chord, 
labelSc  il, 
labels  i2, 
scalarS:  invDr 
)  const 


interpolateWeights (radius. 


twist 

chord 


invDr* (twist_ [i2] 
invDr* (chord  [i2] 


radius  , 

,  il, 

i2 ,  invDr) ; 

twist_ 

[il]  ) 

+  twist_[il] 

chord 

[ill  ) 

+  chord  [il] 

// 


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 
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A.2.7  profileModel.H 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: : prof ileModel 
Description 

Abstract  class  for  profile  models 

SourceFiles 

prof ileModel . C 


\* - */ 

#ifndef  prof ileModel_H 
#define  prof ileModel_H 

#include  "autoPtr.H" 

#include  " runTimeSelectionTables . H" 

#include  "dictionary. H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  profileModel  Declaration 

\* - */ 

class  profileModel 

{ 

protected : 

//  Protected  data 

//-  Coefficients  dictionary 
const  dictionary  dict_; 

//-  Name  of  profile  model 
const  word  name_; 

//-  File  name  (optional) 
fileName  fName_; 


//  Protected  Member  Functions 

//-  Return  ture  if  file  name  is  set 
bool  readFromFile ( )  const; 


public : 

//-  Runtime  type  information 
TypeName ( "prof ileModel " ) ; 
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//  Declare  run-time  constructor  selection  table 
declareRunTimeSelectionTable 
( 

autoPtr, 
prof ileModel , 
dictionary, 

( 

const  dictionaryS:  diet, 
const  wordS:  modelName 

)  , 

(diet,  modelName) 

)  ; 


II  Selectors 

//-  Return  a  reference  to  the  selected  basicSource  model 
static  autoPtr<prof ile]yiodel>  New(const  dictionary^  diet)  ; 


//-  Constructor 

prof  ileModel  (const  dictionaryS:  diet,  const  wordS:  modelName); 


//-  Destructor 
virtual  -prof ileModel (); 


//  Member  functions 
II  Access 

//-  Return  const  access  to  the  source  name 
const  wordS:  name  ( )  const; 


//  Evaluation 

//-  Return  the  Cd  and  Cl  for  a  given  angle-of -attack 
virtual  void  Cdl 
( 

const  scalar  alpha, 
scalarS:  Cd, 
scalarS:  Cl 
)  const  =  0; 

}; 


//*************************************// 
}  //  End  namespace  Foam 

//*************************************// 

#endif 

I j  *************************************************************************  j j 
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A.2.8  profileModel.C 


/* 


*\ 
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\\  / 
\\  / 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  "prof ileModel . H" 

#include  " addToRunTimeSelectionTable . H" 

//*************************************// 

namespace  Foam 

{ 

defineTypeNameAndDebug (prof ileModel ,  0) ; 
defineRunTimeSelectionTable (prof ileModel ,  dictionary) ; 

} 


//*************  Protected  Member  Functions  **********// 

bool  Foam :: prof ileModel :: readFromFile ( )  const 

{ 

return  fName  !=  f ileName : : null ; 

} 


//****************  Constructors  **************// 

Foam:  :prof  ileModel :  :prof  ileModel  (const  dictionaryS:  diet,  const  wordS:  name) 

dict_(dict) , 
name_(name) , 
fName  ( f ileName :: null ) 

{ 

diet . readlf Present (" f ileName" ,  fName  ); 

} 

//*****************  Destructor  **************// 

Foam : : prof ileModel : : -prof ileModel ( ) 

{} 


//***********  Public  Member  Functions  *************  // 

const  Foam:  :word&:  Foam ::  prof  ileModel ::  name  ( )  const 

{ 

return  name  ; 

} 


Foam: : autoPtr<Foam : :prof ileModel>  Foam: : prof ileModel : :New 

( 

const  dictionaryS:  diet 

) 

{ 

const  wordS:  modelName  (diet .  dictName  ( )  )  ; 
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const  word  modelType (diet . lookup (" type ")) ; 

Info<<  "  -  creating  "  <<  modelType  <<  "  profile  "  <<  modelName  <<  endl; 

dictionaryConstructorTable :: iterator  cstrlter  = 

dictionaryConstructorTablePtr_- >f ind (modelType) ; 

if  (cstrlter  ==  dictionaryConstructorTablePtr  ->end()) 

{ 

FatalErrorIn  ( "prof  ileModel :  :New(const  dictionary&i)  ") 

<<  "Unknown  profile  model  type  "  <<  modelType 
<<  nl  <<  nl 

<<  "Valid  model  types  are  : "  <<  nl 
<<  dictionaryConstructorTablePtr_- >sortedToc ( ) 

<<  exit (FatalError) ; 

} 


return  autoPtr<profileModel> (cstrlter ( ) (diet,  modelName)); 

} 

I j  *************************************************************************  j j 
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A.2.9  profileModelList.H 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: : prof ileModelList 
Description 

Base  class  for  profile  models 

SourceFiles 

prof ileModelList . C 


\* - */ 

#ifndef  prof ileModelList_H 
#define  prof ileModelList_H 

#include  "PtrList.H" 

#include  "prof ileModel . H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  prof ileModelList  Declaration 

\* - */ 

class  prof ileModelList 

public  PtrList<prof ileModel> 


protected : 

//  Protected  data 

//-  Dictionary 

const  dictionary  dict_; 


public : 

//-  Constructor 

prof ileModelList (const  dictionary^  diet,  const  bool  readFields  =  true) ; 

//-  Destructor 
-prof ileModelList ( ) ; 


//  Member  Functions 

//-  Set  blade- >profile  addressing 
void  connectBlades 
( 

const  List<word>&:  names. 
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List<label>&:  addr 
)  const; 

}; 

//*************************************// 

}  //  End  namespace  Foam 

//*************************************// 

#endif 

I j  *************************************************************************  / j 
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A.2.10  profileModelList.C 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  "prof ileModelList . H" 

//****************  Constructors  **************// 

Foam: : prof ileModelList : : prof ileModelList 

{ 

const  dictionarySc  diet, 
const  bool  readFields 

) 

PtrList<prof ileModel> ( )  , 
diet  (diet) 

{ 

if  (readFields) 

{ 

wordList  modelNames (diet . toe ( ) ) ; 

Info<<  "  Constructing  blade  profiles:"  <<  endl; 

if  (modelNames . size ( )  >  0) 

{ 

this- >set Size (modelNames . size ( ) ) ; 

forAll (modelNames ,  i) 

{ 

const  words  modelName  =  modelNames [i] ; 

this- >set 

( 

i , 

prof ileModel : : New (diet . subDict (modelName ) ) 

)  ; 


else 

{ 

Info<<  "  none"  <<  endl; 


//*****************  Destructor  **************// 

Foam : : prof ileModelList : : -prof ileModelList ( ) 

{} 


//***************  Member  Functions  *************// 

void  Foam: : prof ileModelList : : connectBlades 

( 
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const  List<word>&:  names, 

List<label>&:  addr 
)  const 
{ 

//  construct  the  addressing  between  blade  sections  and  profiles 
forAll (names ,  bl) 

{ 

label  index  =  -1; 

const  wordS:  profileName  =  names  [bl]  ; 

forAll ( *this ,  pi) 

{ 

const  prof  ileModelS:  pm  =  this- >operator  []  (pi); 
if  (pm. name  0  ==  profileName) 

pi; 


} 


index  = 
break; 


if  (index 


-1) 


List<word>  prof ileNames ( size ( ) ) ; 
forAll ( *this ,  i) 


} 


const  prof  ileModelS:  pm  =  this- >operator  []  (i)  ; 
prof  ileNames  [i]  =  pm.nameO; 


FatalErrorIn  ( "  void  Foam :  :  connectBlades  (List<word>&:  names)  const") 
<<  "Profile  "  <<  profileName  <<  "  could  not  be  found  " 

<<  "in  profile  list.  Available  profiles  are" 

<<  prof ileNames  <<  exit (FatalError) ; 


else 


addr  [bl] 


index ; 


// 


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 
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A.2.11  lookupProfile.H 


/* 


*\ 


W  / 
W  / 
W  / 
W/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: : lookupProf ile 
Description 

Look-up  based  profile  data  -  drag  and  lift  coefficients  are  lineraly 
interpolated  based  on  the  supplied  angle  of  attack 

Input  in  list  format: 

data 

( 

(AOAl  Cdl  C12) 

(A0A2  Cd2  C12) 

(AOAN  CdN  CdN) 

)  ; 

where : 

AOA  =  angle  of  attack  [deg]  converted  to  [rad]  internally 
Cd  =  drag  coefficient 
Cl  =  lift  coefficient 

SourceFiles 

lookupProf ile . C 


\* - */ 

#ifndef  lookupProf ile_H 
#define  lookupProf ile_H 

#include  "prof ileModel . H" 

#include  "List.H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  lookupProf ile  Declaration 

\* - */ 

class  lookupProf ile 

public  profileModel 


protected : 

//  Protected  data 

//-  List  of  angle-of -attack  values  [deg]  on  input,  converted  to  [rad] 
List<scalar>  A0A_; 
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//-  List  of  drag  coefficient  values 

List<scalar>  Cd  ; 

//-  List  of  lift  coefficient  values 

List<scalar>  Cl  ; 

// 

Protected  Member  Functions 

//-  Return  the  interpolation  indices  and  gradient 
void  interpolateWeights 
( 

const  scalarS:  xin, 
const  List<scalar>&:  values, 
labels  il, 
labels  i2, 
scalarS:  ddx 
)  const; 

public 

//-  Runtime  type  information 
TypeName ( " lookup" ) ; 

//-  Constructor 

lookupProfile  (const  dictionaryS:  diet,  const  wordS:  modelName) 


// 

Member  functions 

//  Evaluation 

}; 

//-  Return  the  Cd  and  Cl  for  a  given  angle-of -attack 

virtual  void  Cdl  (const  scalar  alpha,  scalarS:  Cd,  scalarS:  Cl)  const; 

//  *  * 

***********************************  yy 

}  //  End  namespace  Foam 

//*************************************// 

#endif 

1 1  *************************************************************************  j I 
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A.2.12  lookupProfile.C 


/* 


*\ 


W  / 
W  / 
W  / 
W/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011-2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* 


*/ 


#include 

#include 

#include 

#include 

#include 


" lookupProf ile . H" 

" addToRunTimeSelectionTable . H" 
"vector . H" 

" unitConversion . H" 

"IFstream.H" 


//*************************************// 


namespace  Foam 

{ 

def ineTypeNameAndDebug ( lookupProf ile ,  0) ; 

addToRunTimeSelectionTable (prof ileModel ,  lookupProf ile ,  dictionary) ; 

} 


//************  Protected  Member  Functions  ***********  // 

void  Foam: : lookupProf ile : : interpolateWeights 

( 

const  scalarS:  xin, 
const  List<scalar>&:  values, 
labels  il, 
labelSc  i2, 
scalarS:  ddx 
)  const 
{ 

i2  =  0; 

label  nElem  =  values . size () ; 

if  (nElem  ==  1) 

{ 

il  =  i2; 
ddx  =  0.0; 
return; 

} 

else 

{ 

while  ( (values [i2]  <  xIn)  &&  (i2  <  nElem)) 

{ 

i  2  +  +  ; 

} 


(i2  = 

=  nElem) 

i2  = 

nElem  - 

il  = 

i2; 

ddx 

=  0.0; 

return; 

se 

il  = 

i2  -  1; 
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ddx  =  (xin  -  values [il] ) / (values [12]  -  values [il] ) ; 


//****************  Constructors  **************// 

Foam: : lookupProf lie : : lookupProf lie 

{ 

const  dictionary’s:  diet, 
const  wordS:  modelName 

) 

prof ileModel (diet ,  modelName), 

AOA_ ( ) , 

Cd_()  , 

Cl  0 

{ 

List<vector>  data; 
if  (readFromFile ( ) ) 

{ 

IFstream  is(fName_); 
is  >>  data; 

} 

else 

{ 

diet . lookup ( "data" )  >>  data; 

} 

if  (data.sizeO  >  0) 

{ 

AOA_. setSize (data . size ( )  )  ; 

Cd_. setSize (data . size ( ) ) ; 

Cl_. setSize (data . size ( )  )  ; 

f orAll (data ,  i ) 

{ 

AOA_[i]  =  degToRad (data [i]  [0]  )  ; 

Cd_[i]  =  data[i]  [1]  ; 

Cl_[i]  =  data[i]  [2]  ; 


else 

{ 

FatalErrorIn 

( 

"Foam: : lookupProf ile : : lookupProf ile" 

Tl  ^  Il 

"const  dictionaryS:,  " 

"const  wordS:" 

Tl  j  Tl 

)  <<  "No  profile  data  specified"  <<  exit (FatalError) ; 


//***************  Member  Functions  *************// 

void  Foam ::  lookupProf  ile ::  Cdl  (const  scalar  alpha,  scalarS:  Cd,  scalarS:  Cl)  const 

{ 

label  il  =  -1; 
label  i2  =  -1; 
scalar  invAlpha  =  -1.0; 

interpolateWeights (alpha,  AOA_,  il,  i2,  invAlpha); 

Cd  =  invAlpha*  (Cd_[i2]  -  Cd_[il])  +  Cd_[il]; 

Cl  =  invAlpha* (Cl  [i2]  -  Cl  [il] )  +  Cl  [il]  ; 

}  -  -  _ 


j j  *************************************************************************  j j 
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A.2.13  seriesProfile.H 


/* 


*\ 


W  / 
W  / 
W  / 
W/ 


F  ield 
O  peration 
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M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011-2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: : seriesProf ile 


Description 

Series-up  based  profile  data  -  drag  and  lift  coefficients  computed  as 
sum  of  cosine  series 


Cd  =  sum_i (CdCoef f ) *cos (i*A0A) 
Cl  =  sum_i (ClCoef f ) *sin (i*AOA) 


where : 

AOA  =  angle  of  attack  [deg]  converted  to  [rad]  internally 
Cd  =  drag  coefficent 
Cl  =  lift  coefficent 


Input  in  two  (arbitrary  length)  lists: 

CdCoeffs  (coeffl  coeff2  . . .  coeffN) ; 
ClCoeffs  (coeffl  coeff2  . . .  coeffN) ; 


SourceFiles 

seriesProf ile . C 


\* - */ 

#ifndef  seriesProf ile_H 
#define  seriesProf ile_H 

#include  "prof ileModel . H" 

#include  "List.H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  seriesProf ile  Declaration 

\* - */ 

class  seriesProf ile 

public  profileModel 

{ 

protected: 

//  Protected  data 

//-  List  of  drag  coefficient  values 
List<scalar>  CdCoeffs_; 

//-  List  of  lift  coefficient  values 
List<scalar>  ClCoeffs_; 
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//  Protected  Member  Functions 
//  Evaluate 
//-  Drag 

scalar  evaluateDrag 

( 

const  scalarSc  xin, 
const  List<scalar>&:  values 
)  const; 

//-  Lift 

scalar  evaluateLift 

( 

const  scalarS:  xIn, 
const  List<scalar>&:  values 
)  const; 


public : 

//-  Runtime  type  information 
TypeName (" series " ) ; 

//-  Constructor 

seriesProfile  (const  dictionaryS:  diet,  const  wordS:  modelName)  ; 


//  Member  functions 
II  Evaluation 

//-  Return  the  Cd  and  Cl  for  a  given  angle-of -attack 

virtual  void  Cdl  (const  scalar  alpha,  scalarS:  Cd,  scalarS:  Cl)  const; 

}; 

//*************************************// 
}  //  End  namespace  Foam 

//*************************************// 

#endif 

II  *************************************************************************  II 
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A.2.14  seriesProfile.C 


/* 


*\ 


W  / 
W  / 
W  / 
W/ 


F  ield 
O  peration 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2011-2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 

You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  " seriesProf ile . H" 

#include  " addToRunTimeSelectionTable . H" 

#include  "IFstream.H" 

//*************************************// 

namespace  Foam 

{ 

def ineTypeNameAndDebug ( seriesProf ile ,  0) ; 

addToRunTimeSelectionTable (prof ileModel ,  seriesProf ile ,  dictionary) ; 

} 


11  ************  Protected  Member  Functions  ***********  // 

Foam: : scalar  Foam: : seriesProf ile : : evaluateDrag 

( 

const  scalarS:  xin, 
const  List<scalar>&:  values 
)  const 
{ 

scalar  result  =  0.0; 

forAll (values ,  i) 

{ 

result  +=  values [i] *cos (i*xln) ; 

} 


return  result; 

} 


Foam: : scalar  Foam: : seriesProf ile : : evaluateLif t 

( 

const  scalarS:  xIn, 
const  List<scalar>&:  values 
)  const 
{ 

scalar  result  =  0.0; 

forAll (values ,  i) 

{ 

result  +=  values [i] *sin (i*xln) ; 

} 

return  result; 

} 


//****************  Constructors  **************// 
Foam: : seriesProf ile : : seriesProf ile 
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( 

const  dictionary's  diet, 
const  words  modelName 

) 

prof ileModel (diet ,  modelName), 

CdCoef f s_ ( ) , 

ClCoeffs  0 

{ 

if  (readFromFile { ) ) 

{ 

IFstream  is(fName_); 

is  >>  CdCoeffs  >>  ClCoeffs  ; 

} 

else 

{ 

diet . lookup (" CdCoef fs " )  >>  CdCoeffs_; 
diet . lookup (" ClCoeffs " )  >>  ClCoeffs  ; 

} 


if  (CdCoeffs  .emptyO) 

{ 

FatalErrorIn 

( 

"Foam: : seriesProf ile : : seriesProf ile" 

II  ^  II 

"eonst  dietionaryS:,  " 

"eonst  wordS:" 

II  j  II 

)  <<  "CdCoeffs  must  be  speeified"  <<  exit (FatalError) 

} 

if  (ClCoeffs  .emptyO) 

{ 

FatalErrorIn 

( 

"Foam: : seriesProf ile : : seriesProf ile" 

II  ^  II 

"eonst  dietionaryS:,  " 

"eonst  word&i" 

II  j  II 

)  <<  "ClCoeffs  must  be  speeified"  <<  exit (FatalError) , 


//***************  Member  Funetions 


★  ★★★★★★★★★★★★ 


// 


void  Foam:  :  seriesProf  ile  ::  Cdl  (eonst  sealar  alpha,  sealarS:  Cd,  sealarS:  Cl)  eonst 

{ 


Cd  =  evaluateDrag (alpha,  CdCoeffs_) ; 
Cl  =  evaluateLift (alpha,  ClCoeffs_) ; 


// 


1 1 
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A.2.15  trimModel.H 


/* 


*\ 


W  / 
W  / 
W  / 
W/ 


F  ield 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: :trimModel 
Description 

Trim  model  abstract  class 


SourceFiles 

trimModel . C 


\* - */ 

#ifndef  trimModel_H 
#define  trimModel_H 

#include  " rotorDiskSource . H" 

#include  "dictionary . H" 

#include  " runTimeSelectionTables . H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  trimModel  Declaration 

\* - */ 

class  trimModel 

{ 

protected : 

//  Protected  data 

//-  Reference  to  the  rotor  source  model 
const  rotorDiskSourceSc  rotor_; 

//-  Name  of  model 
const  word  name_; 

//-  Coefficients  dictionary 
dictionary  coeffs_; 


public : 

//-  Run-time  type  information 
TypeName (" trimModel " ) ; 


//  Declare  runtime  constructor  selection  table 

declareRunTimeSelectionTable 

( 
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autoPtr, 
trimModel , 
dictionary, 

( 

const  rotorDiskSourceS:  rotor, 
const  dictionaryS:  diet 

)  , 

(rotor,  diet) 

)  ; 


//  Constructors 

//-  Construct  from  components 
trimModel 
( 

const  rotorDiskSourceS:  rotor, 
const  dictionaryS:  diet, 
const  wordS:  name 

)  ; 


//  Selectors 

//-  Return  a  pointer  to  the  selected  trim  model 
static  autoPtr<trimModel>  New 
( 

const  rotorDiskSourceS:  rotor, 
const  dictionaryS:  diet 

)  ; 


//-  Destructor 
virtual  -trimModel (); 


//  Member  functions 
//-  Read 

virtual  void  read(const  dictionaryS:  diet)  ; 

//-  Return  the  geometric  angle  of  attack  [rad] 
virtual  tmp<scalarField>  alphagO  const  =  0; 

//-  Correct  the  model 

virtual  void  correct  (const  vectorFieldS:  U,  vectorFieldS:  force)  =  0; 

}; 

//*************************************// 
}  //  End  namespace  Foam 

//*************************************// 

#endif 

I j  *************************************************************************  j j 
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A.2.16  trimModel.C 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  " trimModel . H" 

//**************  static  Data  Members  *************// 

namespace  Foam 

{ 

defineTypeNameAndDebug (trimModel ,  0) ; 
defineRunTimeSelectionTable (trimModel ,  dictionary) ; 

} 


//****************  Constructors  **************// 

Foam: : trimModel: : trimModel 

( 

const  rotorDiskSourceSc  rotor, 
const  dictionaryS:  diet, 
const  wordS:  name 

) 

rotor_ (rotor) , 
name_(name) , 

coeffs  (dictionary: :null) 

{ 

read (diet ) ; 

} 

//*****************  Destructor  **************// 

Foam : : trimModel : : -trimModel ( ) 

{} 


//***************  Member  Functions  *************// 

void  Foam:  :  trimModel ::  read  (const  dictionaryS:  diet) 

{ 

coeffs  =  diet . subDict (name  +  "Coeffs"); 

} 


j j  *************************************************************************  j j 
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A.2.17  trimModelNew.C 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  " trimModel . H" 

//****************  Constructors  **************// 

Foam: : autoPtr<Foam: :trimModel>  Foam: : trimModel: :New 

{ 

const  rotorDiskSourceSc  rotor, 
const  dictionaryS:  diet 

) 

{ 

const  word  modelType (diet . lookup (typeName) ) ; 

Info<<  "  Selecting  "  <<  typeName  <<  "  "  <<  modelType  <<  endl; 

dictionaryConstructorTable :: iterator  cstrlter  = 

dictionaryConstructorTablePtr_- >f ind (modelType) ; 

if  (cstrlter  ==  dictionaryConstructorTablePtr  ->end()) 

{ 

FatalErrorIn 

( 

"trimModel :  :New(const  rotorDiskSourceSc,  const  dictionarySc)  " 

)  <<  "Unknown  "  <<  typeName  <<  "  type  " 

<<  modelType  <<  nl  <<  nl 

<<  "Valid  "  <<  typeName  <<  "  types  are:"  <<  nl 
<<  dictionaryConstructorTablePtr_- >sortedToc ( ) 

<<  exit (FatalError) ; 

} 

return  autoPtr<trimModel> (cstrlter ( ) (rotor,  diet)); 

} 


// 


// 
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A.2.18  fixedTrim.H 


/* 


*\ 
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OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: :fixedTrim 
Description 

Fixed  trim  coefficients 


SourceFiles 

f ixedTrim. C 


\* - */ 

#ifndef  fixedTrim_H 
#define  fixedTrim_H 

#include  " trimModel . H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  fixedTrim  Declaration 

\* - */ 

class  fixedTrim 

public  trimModel 


protected : 

//  Protected  data 

//-  Geometric  angle  of  attack  [rad] 
scalarField  alphag_; 


public : 

//-  Run-time  type  information 
TypeName ( "fixedTrim" ) ; 

//-  Constructor 

fixedTrim  (const  rotorDiskSourceSc  rotor,  const  dictionarySc  diet)  ; 

//-  Destructor 
virtual  ~f ixedTrim (); 


//  Member  functions 
//-  Read 

void  read(const  dictionarySc  diet); 
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//-  Return  the  geometric  angle  of  attack  [rad] 
virtual  tmp<scalarField>  alphagO  const; 

//-  Correct  the  model 

virtual  void  correct  (const  vectorFieldS:  U,  vectorFieldS:  force); 

}; 

//*************************************// 
}  //  End  namespace  Foam 

//*************************************// 

#endif 

I j  *************************************************************************  j j 
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A.2.19  fixedTrim.C 


/* 


*\ 


\\  / 
\\  / 
\\  / 
\\/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 

You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  "fixedTrim.H" 

#include  " addToRunTimeSelectionTable . H" 

#include  "unitConversion . H" 

#include  "mathematicalConstants . H" 

using  namespace  Foam :: constant ; 

//**************  static  Data  Members  *************// 

namespace  Foam 

{ 

def ineTypeNameAndDebug ( f ixedTrim,  0) ; 

addToRunTimeSelectionTable (trimModel ,  fixedTrim,  dictionary); 

} 


//****************  Constructors  **************// 

Foam: : fixedTrim: : fixedTrim (const  rotorDiskSourceS:  rotor,  const  dictionary^  diet) 

trimModel (rotor ,  diet,  typeName) , 
alphag  (rotor . cells (). size () ,  0.0) 

{ 

read (diet ) ; 

} 


//*****************  Destructor  **************// 

Foam: : fixedTrim: : -fixedTrim ( ) 

{} 


//***************  Member  Functions  *************// 

void  Foam:  :  fixedTrim:  :  read  (const  dictionarySc  diet) 

{ 

trimModel: : read (diet) ; 

scalar  alphaC  =  degToRad (readScalar (coeffs_. lookup ( "alphaC" ))) ; 
scalar  A  =  degToRad (readScalar (coeffs_. lookup ( "A" ))) ; 
scalar  B  =  degToRad (readScalar (coeffs_. lookup ( "B" ))) ; 

const  List<vector>&:  x  =  rotor_.x(); 
forAll (alphag  ,  i) 

{ 

scalar  psi  =  x[i]  .y()  ; 

alphag__[i]  =  alphaC  +  A*cos(psi)  +  B*sin(psi); 
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Foam: : tmp<Foam: : scalarField>  Foam: : f ixedTrim: : alphag ( )  const 

{ 

return  tmp<scalarField> (alphag  ); 

} 


void  Foam:  :  f  ixedTrim:  :  correct  (const  vectorFieldS:  U,  vectorFieldS:  force) 

{ 

//  do  nothing  -  untrimmed  model 

} 


11  *************************************************************************  j j 
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A.2.20  targetForceTrim.H 


/* 


\\  / 
\\  / 
\\  / 
\\/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


*\ 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 

You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 

Class 

Foam: : targetForceTrim 
Description 

Target  force  trim  coefficients 

SourceFiles 

targetForceTrim. C 


\* - */ 

#ifndef  targetForceTrim_H 
#define  targetForceTrim_H 

#include  " trimModel . H" 

#include  " tensor. H" 

#include  "vector. H" 

//*************************************// 

namespace  Foam 

{ 

/* - *\ 

Class  targetForceTrim  Declaration 

\* - */ 

class  targetForceTrim 
public  trimModel 

{ 

protected: 

//  Protected  data 

//-  Number  of  iterations  between  calls  to  'correct' 
label  calcFrequency_; 

//-  Target  force  [N] 
vector  target_; 

//-  Pitch  angles  (collective,  roll,  pitch)  [rad] 
vector  alpha_; 

//-  Maximum  number  of  iterations  in  trim  routine 
label  nlter_; 

//-  Convergence  tolerance 
scalar  tol_; 

//-  Under-relaxation  coefficient 
scalar  relax_; 
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//-  Perturbation  angle  used  to  determine  jacobian 
scalar  dTheta_; 


//  Protected  member  functions 

//-  Calculate  the  rotor  forces 
vector  calcForce 
( 

const  vectorFieldS:  U, 
const  scalarFieldS:  alphag, 
vectorFieldS:  force 
)  const; 


public : 

//-  Run-time  type  information 
TypeName ( " targetForceTrim" ) ; 

//-  Constructor 

targetForceTrim (const  rotorDiskSourceS:  rotor,  const  dictionary^  diet) ; 

//-  Destructor 

virtual  -targetForceTrim (); 


//  Member  functions 
//-  Read 

void  read(const  dictionary^  diet) ; 

//-  Return  the  geometric  angle  of  attack  [rad] 
virtual  tmp<scalarField>  alphag ()  const; 

//-  Correct  the  model 

virtual  void  correct  (const  vectorFieldS:  U,  vectorFieldS:  force); 

}; 

//*************************************// 
}  //  End  namespace  Foam 

//*************************************// 

#endif 

j !  *************************************************************************  j j 
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A.2.21  targetForceTrim.C 


/* 


*\ 


W  / 
W  / 
W  / 
W/ 


F  ield 
O  peration 
A  nd 

M  anipulation 


OpenFOAM:  The  Open  Source  CFD  Toolbox 
Copyright  (C)  2012  OpenFOAM  Foundation 


License 

This  file  is  part  of  OpenFOAM. 

OpenFOAM  is  free  software:  you  can  redistribute  it  and/or  modify  it 
under  the  terms  of  the  GNU  General  Public  License  as  published  by 
the  Free  Software  Foundation,  either  version  3  of  the  License,  or 
(at  your  option)  any  later  version. 

OpenFOAM  is  distributed  in  the  hope  that  it  will  be  useful,  but  WITHOUT 
ANY  WARRANTY;  without  even  the  implied  warranty  of  MERCHANTABILITY  or 
FITNESS  FOR  A  PARTICULAR  PURPOSE.  See  the  GNU  General  Public  License 
for  more  details. 


You  should  have  received  a  copy  of  the  GNU  General  Public  License 
along  with  OpenFOAM.  If  not,  see  <http://www.gnu.org/licenses/>. 


\* - */ 

#include  "targetForceTrim.H" 

#include  " addToRunTimeSelectionTable . H" 

#include  "unitConversion . H" 

#include  "mathematicalConstants . H" 

using  namespace  Foam :: constant ; 

//**************  static  Data  Members  *************// 

namespace  Foam 

{ 

def ineTypeNameAndDebug (targetForceTrim,  0) ; 

addToRunTimeSelectionTable (trimModel ,  targetForceTrim,  dictionary) ; 

} 


//************  Protected  Member  Functions  ***********// 

Foam: : vector  Foam: : targetForceTrim: :calcForce 

{ 

const  vectorFieldSc  U, 
const  scalarFieldS:  alphag, 
vectorFieldS:  force 
)  const 
{ 

rotor_. calculate (U,  alphag,  force,  false); 

const  labelListS:  cells  =  rotor_.  cells  ()  ; 
const  vectorFieldS:  C  =  rotor_.mesh  ( )  .CO  ; 

const  vectors:  origin  =  rotor_.  coordSys  ().  origin  ()  ; 
const  vectors:  rollAxis  =  rotor_.  coordSys  ().  el  ()  ; 
const  vectors:  pitchAxis  =  rotor_.  coordSys  ().  e2  {)  ; 
const  vectors:  yawAxis  =  rotor_.  coordSys  ( )  .  e3  ( )  ; 

vector  f (vector :: zero) ; 
forAll (cells ,  i) 

{ 

label  celll  =  cells  [i]  ; 

vector  moment  =  force  [celll]  (C  [celll]  -  origin);  //cross  product 
f  [0]  +=  force  [celll]  S:  yawAxis;  //dot  product 
f  [1]  +=  moment  Se.  pitchAxis; 
f  [2]  +=  moment  S:  rollAxis; 

} 

reduce (f,  sumOp<vector> ( ) ) ; 
return  f ; 

} 
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//****************  Constructors  **************// 

Foam: : targetForceTrim : : targetForceTrim 

{ 

const  rotorDiskSourceS:  rotor, 
const  dictionary’s:  diet 

) 

trimModel (rotor ,  diet,  typeName) , 

calcFrequency_ ( - 1 ) , 

target_ (vector: :zero) , 

alpha_ (vector : :zero)  , 

nlter_(50) , 

tol_(le-8) , 

relax_(1.0) , 

dTheta  (degToRad ( 0 . 05 ) ) 

{ 

read (diet ) ; 

} 


//*****************  Destructor  **************// 

Foam: : targetForceTrim : : -targetForceTrim ( ) 

{} 


//***************  Member  Functions  *************// 

void  Foam :: targetForceTrim :: read 

( 

const  dictionaryS:  diet 

) 

{ 

trimModel: : read (diet) ; 

const  dictionaryS:  targetDict  (coeffs_.  subDict  ( "target" ))  ; 

const  bool  IsCompressible  =  rotor_. getRhoName ( )  !=  "none"; 

if  (IsCompressible  !=  0) 

{ 

target_[0]  =  readScalar (targetDict . lookup (" f Thrust ")) ; 
target_[l]  =  readScalar (targetDict . lookup ( "mPitch" )) ; 
target  [2]  =  readScalar (targetDict . lookup ( "mRoll" )) ; 

} 

if  (IsCompressible  ==  0) 

{ 

target_  [0]  =  (readScalar  (targetDict .  lookup  ( "  f Thrust " )  )  )  /  (rotor__.  getRhoRef  ( )  ) 
target_ [1]  =  (readScalar (targetDict . lookup ( "mPitch" ) ) ) / (rotor_. getRhoRef ( ) ) ; 
target  [2]  =  (readScalar (targetDict . lookup ( "mRoll" )))/ (rotor  . getRhoRef ()) ; 

} 


const  dictionaryS:  pitchAngleDict (coef f s_. subDict ( "pitchAngles " ) ) ; 
alpha_[0]  =  degToRad (readScalar (pitchAngleDict . lookup ( "alphaCIni" ) ) ) ; 
alpha_[l]  =  degToRad (readScalar (pitchAngleDict . lookup ( "AIni" ) ) ) ; 
alpha_[2]  =  degToRad (readScalar (pitchAngleDict . lookup ( "BIni" ) ) ) ; 

coef fs_. lookup ( "calcFrequency" )  >>  calcFrequency_; 

coef fs_. readlf Present ( "niter" ,  nlter_) ; 
coef f s_. readlfPresent ( "tol" ,  tol_) ; 
coef fs_. readlfPresent ( "relax" ,  relax_) ; 

if  (coeffs  . readlf Present ( "dTheta" ,  dTheta  )) 

{ 

dTheta_  =  degToRad (dTheta_) ; 


Foam: :tmp<Foam: : scalarField>  Foam: : targetForceTrim : :alphag()  const 

{ 

const  List<vector>S:  x  =  rotor_.x(); 

tmp<scalarField>  ta (new  scalarField (x . size ( ) ) ) ; 
scalarFieldS:  a  =  ta(); 

forAll (a,  i) 
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{ 

scalar  psi  =  x[i]  .y()  ; 

a[i]  =  alpha_[0]  +  alpha_  [1]  *cos  (psi)  +  alpha__  [2]  *sin  (psi)  ; 


return  ta; 

} 


void  Foam:  :  targetForceTrim:  :  correct  (const  vectorFieldS:  U,  vectorFieldS:  force) 

{ 

if  (rotor  .meshO  .timeO  .timeIndexO  %  calcFrequency  ==  0) 

{ 

//  iterate  to  find  new  pitch  angles  to  achieve  target  force 

scalar  err  =  GREAT; 

label  iter  =  0; 

tensor  J (tensor :: zero) ; 

while  ( (err  >  tol  )  &&  (iter  <  niter  ) ) 

{ 

//  cache  initial  alpha  vector 
vector  alphaO (alpha_) ; 

//  set  initial  values 

//  gets  re- initialised  everytime  this  function  is  called 
vector  old  =  calcForce(U,  alphagO,  force); 

//  construct  Jacobian  by  perturbing  the  pitch  angles 
//  by  +/- (dTheta_/2) 

for  (label  pitchl  =  0;  pitchl  <  3;  pitchl++) 

{ 

alpha_ [pitchl]  -=  dTheta_/2.0; 

vector  fO  =  calcForce(U,  alphagO,  force); 

alpha_ [pitchl]  +=  dTheta_; 

vector  fl  =  calcForce(U,  alphagO,  force); 

vector  ddTheta  =  (fl  -  fO)/dTheta_; 

J [pitchl  +  0]  =  ddTheta [0]; 

J  [pitchl  +  3]  =  ddTheta [1]  ; 

J  [pitchl  +  6]  =  ddTheta [2]  ; 

alpha  =  alphaO; 

} 

//  calculate  the  change  in  pitch  angle  vector 
vector  dAlpha  =  inv(J)  &  (target_  -  old) ; 

//  update  pitch  angles 

vector  alphaNew  =  alpha__  +  re lax_* dAlpha  ; 

//  update  error 

err  =  mag (alphaNew  -  alpha_) ; 

//  update  for  next  iteration 
alpha_  =  alphaNew; 

//  next  iteration 
iter++ ; 

} 


const  bool  IsCompressible  =  rotor_. getRhoName ()  !=  "none"; 

if  (iter  ==  niter  ) 

{ 

Warningin 

( 

"void  Foam: : targetForceTrim: : correct" 

Tl  ^  Tl 

"const  vectorFieldSc,  " 

"  vectorField&i" 

Tl  j  Tl 

)  <<  "  Trim  routine  not  converged  in  "  <<  iter 

<<  "  iterations,  max  residual  =  "  <<  err  <<  endl; 

} 

else 

{ 

if  (IsCompressible) 

{ 
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} 


} 

if 

{ 


} 


Info<<  type ( )  <<  " :  Target  Force  and  Moments  "  <<  nl 

<<  "  Target  Thrust  z=  "  <<  target_.x()  <<  nl 

<<  "  Target  Pitching  Moment  =  "  <<  target_.y()  <<  nl 

<<  "  Target  Rolling  Moment  =  "  <<  target_.z()  <<  nl 

<<  "  isCompressible  =  "  <<  IsCompressible  <<  endl; 

( ! IsCompressible) 

Info<<  type ( )  <<  " :  Target  Force  and  Moments  "  <<  nl 
<<  "  Target  Thrust  =  " 

<<  ( target_. X ( ) *rotor_. getRhoRef ( ) )  <<  nl 
<<  "  Target  Pitching  Moment  =  " 

<<  (target_. y 0 *rotor_. getRhoRef {) )  <<  nl 
<<  "  Target  Rolling  Moment  =  " 

<<  (target_. z 0 *rotor_. getRhoRef 0 )  <<  nl 

<<  "  isCompressible  =  "  <<  IsCompressible  <<  endl; 


Info<<  type { )  <<  " :  converged  in  "  <<  iter  <<  "  iterations"  <<  nl 
<<  "  residual  =  "  <<  err  <<  endl; 

} 


Info<< 
<  < 
<< 
<  < 
<  < 


new 


II 


endl  ; 


pitch  angles: 
alphaC  =  "  << 
A  =  "  << 
B  =  "  << 


"  <<  nl 

radToDeg (alpha_ [0] ) 
radToDeg (alpha_ [1] ) 
radToDeg (alpha_ [2] ) 


<<  nl 
<<  nl 
<<  nl 


// 


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 
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A.2.22  Make/files 


rotorDiskSource . C 
bladeModel/bladeModel . C 
prof ileModel/prof ileModel . C 
prof ileModel/prof ileModelList . C 
prof ileModel/lookup/lookupProf ile . C 
prof ileModel /series /seriesProfile . C 
trimModel/trimModel/trimModel . C 
trimModel/trimModel/trimModelNew. C 
trimModel/f ixed/f ixedTrim. C 
trimModel /target Force /targetForceTrim. C 

LIB=$ (FOAM_USER_LIBBIN) /librotorDiskSource 


A.2.23  Make/options 

EXE_INC  =  \ 

-DFULL_DEBUG  -g  -OO  \ 

-1$ (LIB_SRC) /meshTools/lnInclude  \ 
-1$ (LIB_SRC) /f initeVolume/lnlnclude 

LIB_LIBS  =  \ 

-ImeshTools  \ 

- If initeVolume 
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Appendix  B  A  Sample  Case  Set  Up  using  the  Georgia 
Tech  Validation  Case  for  Running 
rhoSimpleSourceFoam  Solver  with  rotorDiskSource 

Active 


B.l.  Overview 

This  appendix  provides  a  copy  of  the  OpenFOAM  case  files  used  for  running  the  Georgia 
Tech  Rotor-Airframe  Validation  Case  using  OpenFOAM  2.1.x.  The  purpose  of  this 
appendix  is  to  provide  user  with  an  example  of  a  typical  case  setup  needed  for  running  a 
steady  compressible  (pressure-based)  solver,  rhoSimpleSourceFoam,  using  the 
rotorDiskSource  library. 

The  mesh  files  have  been  omitted  from  this  Appendix.  However,  to  aid  in  providing  a 
context  for  the  boundary  conditions  set  up,  the  "constant /polyMesh/boundary"  file 
have  been  included.  The  "boundary"  file  provides  the  list  of  the  names  of  the  domain 
boundary  patches  included  in  the  mesh. 

The  current  setup  assumes  that  there  is  one  rotor  disk  cell  Zone  included  in  the  mesh, 
named  rotorcell.  The  targetForce  trim  is  used  with  the  same  trim  parameters  as 
those  specified  in  Section  5.4.3. 

Table  B.l  presents  a  sorted  list  of  the  case  configuration  files  shown  in  Section  B.2.  To 
improve  readability,  comments  in  the  code  have  been  shown  in  blue. 


Table  B.l:  Summary  of  a  sample  rhoSimpleSourceFoam  case  configuration  files 


Section 

path/filename 

(path  is  assumed  to  be  relative  to 
the  case  PWD) 

Description 

constant/  polyMesh/boundary 

Contains  patch  names  and  addressing.  This  file  is  part 
of  the  mesh  files,  which  is  automatically  generated 
during  mesh  conversion  process,  or  by  using 
blockMesh 

constant/  RASProperties 

Contains  RANS  turbulence  model  selection 

constant/ thermophysicalProperties 

Contains  the  fluid  thermophysical  properties,  such  as 
molecular  viscosity  and  Prandtl  number 

constant/  transportProperties 

Contains  the  fluid  transport  model  selection,  such  as 
Newtonian  or  Bird-Carreau,  etc. . . 

constant/  sourcesProperties 

Contains  selections  and  definitions  of  field  sources, 
such  as  the  rotorDiskSource 

Multiple  sources  (even  of  varying  types)  must  be 
defined  in  this  file. 

0/p 

Boundary  condition  for  pressure 

0/U 

Boundary  condition  for  velocity 

0/T 

Boundary  condition  for  temperature 

0/k 

Boundary  condition  for  turbulent  kinetic  energy 

0/ epsilon 

Boundary  condition  for  turbulent  dissipation  rate 

Table  continues  over  page  . . . 
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Table  continued  ... 


Section 

path/filename 

(path  is  assumed  to  be  relative  to 
the  case  PWD) 

Description 

0/mut 

Boundary  condition  for  turbulent  viscosity 

0/alphat 

Boundary  condition  for  turbulent  heat  dissipation 
coefficient 

system/  controlDict 

Contains  runtime  control  parameters,  such  as  startTime, 
endXime,  saveinterval,  etc. . . 

system/  fvSchemes 

Contains  numerical  discretisation  schemes  selections 

system/  fvSolution 

Contains  linear  solvers  selections  and  URF 
specifications 

system/  decomposeParDict 

Contains  domain  decomposition  methods  and  setup 
parameters 

monitorResiduals 

A  simple  Gnuplot  script  that  can  be  used  to  plot 
residuals  during  runtime 

runCaseOnSeadragonCluster 

A  sample  PBS  script  that  can  be  used  to  submit  a  job 
through  the  PBS  installation  on  a  cluster 

B.2.  Case  Configuration  Files 

B.2.1  Constant/ poly  Mesh/boundary 


C+  + 


W 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

W 

/ 

0 

peration 

Version : 

2.1.x 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version  2.0; 

format  ascii; 

class  polyBoundaryMesh; 

location  " constant/polyMesh" ; 
object  boundary; 

} 

// 

4 
( 


) 

// 


★  ★★★★★★★ 

★  ★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 

inlet 

/ 

\ 

type 

patch; 

nFaces 

82; 

startFace 

451463 ; 

1 

outlet 

/ 

\ 

type 

patch; 

nFaces 

80; 

StartFace 

1 

451545; 

) 

wall-tunnel 

; 

\ 

type 

wall  ; 

nFaces 

1084  ; 

StartFace 

451625; 

1 

wall -body 

{ 

type 

wall  ; 

nFaces 

5756  ; 

StartFace 

} 

452709; 

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 

// 


// 
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B.2.2  constant/ RASProperties 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
obj  ect 


2.0; 
ascii ; 
dictionary; 
RASProperties ; 


} 

//*************************************// 
RASModel 


kEpsilon;  //realizableKE ; 

on; 

on; 


0.09; 

1.44; 

1.92; 

-0.33; 

1.0; 

1.11;  //Original  value  is  1.44 
1.0; 


turbulence 

printCoef f s 

kEps i lonCoe  f  f  s 

{ 

Cmu 
Cl 
C2 
C3 

sigmak 
sigmaEps 
Prt 

} 

j j  ************************************************************************* 


// 
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B.2.3  constant/  thermophysicalProperties 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

2.0.0 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version  2.0; 

format  ascii; 

class  dictionary; 

location  "constant"; 

obj  ect  thermophysicalProperties ; 


} 

// 


// 


thermoType 

hPsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perf ectGas>>>>> ; 

mixture 

{ 

specie 


nMoles 


1; 


molWeight  28.966; 

} 

thermodynamics 


Cp 

Hf 


1006 . 43  ; 

0.0;  //not  used  -  no  heat  release 


transport 


mu 

Pr 


17 . 894e-06 ; 
0.7; 


// 


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 
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B.2.4  constant/  transportProperties 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version  2.0; 

format  ascii; 

class  dictionary; 

object  transportProperties; 

} 

//*************************************// 
transportModel  Newtonian; 

nu  nu  [02-10000]!. 5e -05; 

j j  *************************************************************************  II 
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B.2.5  constant/  sourcesProperties 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
location 
obj  ect 


2.0; 
ascii ; 
dictionary; 

" constant " ; 
sourcesProperties ; 


// 


// 


mainrotor  //arbitrary  object  name 

{ 


type 

active 

timeStart 

duration 

select ionMode 

cellZone 


rotorDisk; 

on; 

0.0; 

100000 . 0  ; 
cellZone ; 
rotorcell ; 


rotorDiskCoef f s 
{ 

f ieldNames 

(U)  ; 

rhoName 

none  ; 

rhoRef 

1.225; 

rotorDebugMode 

false ; 

rotorURF 

1.0; 

// 

geome  t  ryMode 

specified; 

// 

origin 

(0.456998  0.0  0.137100; 

// 

axis 

(0  0  1)  ; 

// 

ref Direction 

(1  0  0)  ; 

geomet ryMode 

auto; 

ref Direction 

(1  0  0)  ; 

pointAbove 

(0  0  1)  ; 

rpm 

2100  ; 

nBlades 

2; 

inlet FlowType 

local ; 

tipEf f ect 

0.96; 

f lapCoef f s 
{ 

betaO 

0  ; 

betal 

1.94; 

beta2 

} 

2.03; 

trimModel 

targetForceTrim;  //  tare 

f ixedTrimCoef f s 
{ 

alphaC 

10; 

A 

0; 

B 

0 ; 

targetForceTrimCoef f s 

{ 


target 

{ 

fThrust 

mRoll 

mPitch 

} 

pitchAngles 

{ 

alphaCIni 


72.8; 

0; 

0  ; 


5; 
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AIni  0; 

BIni  0; 

} 

calcFrequency  5; 
dTheta  0.1; 

relax  1; 

} 


// 

// 


blade 


data 

( 


(NACA0015-ser 

{NACA0015-ser 


//radius  twist  chord 


(  000. 086) ) 
(0.456978  0  0.086) ) 


( NACAO  0 1 5  -  Lookup 
( NACAO  0 1 5  -  Lookup 

)  ; 

} 


(  000. 086) ) 
(0.456978  0  0.086) ) 


profiles 

{ 

NACA0015-ser 

{ 

type  series; 

CdCoef f s 

( 

1.09853905176285  -0.0254111379715975  -1.01464921175951 
0.000297893132963066  -0.0805674417410576  0.0003478832627729604 
0.0183641071501486  -0.00187212740610965  0.00738154463596278 
-0.0271646860125189  -0.0201573706491855  0.00310230620458444 
-0.00738192972395497  0.0172792907248443  0.0141795478822924 
0 . 0228307118297743 

)  ; 

ClCoef f s 

( 

0.0  0.122067939602577  1.12197137626962  -0.0198082665751631 
0.091486923514929  0.0146427968325049  0.0511391044755384 
0.0158813079932265  0.105584091108421  0.00367478325400266 
0.127744823649244  -0.00715619228634737  0.100691143636163 
-0.0108010398622889  0.0564061685913662  -0.00846889180607761 

)  ; 

} 


NACAO  0 1 5  -  Lookup 
{ 


type 

data 

lookup 

//alpha 

Cd 

Cl 

-180 

0 . 02 

0  ) 

-175 

0 . 06 

0.49  ) 

-170 

0 . 13 

0.75  ) 

-165 

0 . 24 

0.68  ) 

-160 

0 . 3 

0.65  ) 

-140 

1 . 04 

1  ) 

-120 

1 . 65 

0.75  ) 

-110 

1 . 85 

0.48  ) 

-100 

2 . 02 

0.21  ) 

-90 

2 . 02 

-0.06  ) 

-80 

1.96 

-0.34  ) 

-70 

1 . 84 

-0.61  ) 

-60 

1.66 

-0.88  ) 

-50 

1.39 

-1.15  ) 

-30 

0 . 56 

-0.98  ) 

-20 

0.35 

-0.75  ) 

-19 

0.28 

-0.76  ) 

-18 

0 .21 

-0.77  ) 

-17 

0 . 17 

-0.78  ) 

-16 

0 . 15 

-0.79  ) 

-15 

0 . 14 

-0.83  ) 

-14 

0 . 14 

-0.86  ) 

-13 

0 . 1 

-0.93  ) 

-12 

0 . 04 

-1  ) 

-11 

0 . 02 

-0.99  ) 

-10 

0 . 02 

-0.94  ) 

-9 

0 . 02 

-0.87  ) 

-8 

0 . 02 

-0.79  ) 

-7 

0 . 01 

-0.7  ) 

-6 

0 . 01 

-0.61  ) 
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( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 


-5 

0  , 

.  01 

- 

0 . 52 

-4 

0  , 

.  01 

- 

0 .43 

-3 

0  , 

.  01 

- 

0 . 32 

-2 

0  , 

.  01 

- 

0.22 

-1 

0  , 

.  01 

- 

0 . 11 

0 

0  , 

.  01 

0 

1 

0  , 

.  01 

0 

.  11 

2 

0  , 

.  01 

0 

.22 

3 

0  , 

.  01 

0 

.32 

4 

0  , 

.  01 

0 

.  43 

5 

0  , 

.  01 

0 

.52 

6 

0  , 

.  01 

0 

.61 

7 

0  , 

.  01 

0 

.  7 

8 

0  , 

.  02 

0 

.79 

9 

0  , 

.  02 

0 

.87 

10 

0  , 

.  02 

0 

.94 

11 

0  , 

.  02 

0 

.99 

12 

0  , 

.  04 

1 

13 

0  , 

.  1 

0 

.93 

14 

0  , 

.  14 

0 

.86 

15 

0  , 

.  14 

0 

.83 

16 

0  , 

.  15 

0 

.  79 

17 

0  , 

.  17 

0 

.78 

18 

0  , 

.21 

0 

.  77 

19 

0  , 

.28 

0 

.  76 

20 

0  , 

.  35 

0 

.  75 

30 

0  , 

.56 

0 

.98 

50 

1 , 

.39 

1 

.  15 

60 

1 , 

.  66 

0 

.88 

70 

1 , 

.84 

0 

.  61 

80 

1 , 

.96 

0 

.  34 

90 

2  , 

.  02 

0 

.  06 

100 

2  , 

.  02 

- 

0.21 

110 

1 , 

.  85 

- 

0 .48 

120 

1 , 

.65 

- 

0 . 75 

140 

1 , 

.  04 

- 

1 

160 

0  , 

.  3 

- 

0 . 65 

165 

0  , 

.24 

- 

0.68 

170 

0  , 

.  13 

- 

0 . 75 

175 

0  , 

.  06 

- 

0 .49 

180 

0  . 

.  02 

0 

/* 

ADD  NEW  ROTOR  HERE 


) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 


tailrotor  //arbitrary  object  name 

{ 


type 

active 

timeStart 

duration 

select ionMode 

cellZone 


rotorDisk; 

on; 

0.0; 

100000.0; 
cellZone ; 
rotorcell ; 


rotorDiskCoef f s 

{ 


...  } 

*/ 
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B.2.6  0/p 


/* - *_  C++  -* - *\ 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - */ 


FoamFile 

{ 

version 
format 
class 
obj  ect 

} 

/  y  *  *  *  *  * 


2.0; 
ascii ; 

volScalarField; 

p; 


********************************  y'y' 


dimensions 


[1  -1  -2  0  0  0  0]; 


internalField  uniform  101325; 


boundaryField 

{ 

wall -tunnel 

{ 

type  zeroGradient ; 

} 

wall -body 

{ 

type  zeroGradient; 

} 

outlet 

{ 


type 

totalPressure ; 

U 

U; 

phi 

phi  ; 

rho 

rho; 

psi 

psi  ; 

gamma 

1.4; 

po 

} 

uniform  101325 

inlet 

{ 

type  zeroGradient; 

} 


} 

I j  *************************************************************************  j I 
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B.2.7  0/U 


/* - *_  C++  -* - *\ 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - */ 


FoamFile 

{ 

version  2.0; 

format  ascii; 

class  volVectorField; 

location  "0"; 

object  U; 

} 

//*************************************// 

dimensions  [01-10000]; 

internalField  uniform  (10  0  0); 

boundaryField 

{ 

wall-tunnel 

{ 

type 
value 

} 


f ixedValue ; 
uniform  (0  0  0 ) ; 


wall -body 

{ 

type 

value 

} 


f ixedValue ; 
uniform  (0  0  0 ) ; 


outlet 

{ 

type 

value 


pressurelnletOutletVelocity ; 
uniform  (10  0  0 ) ; 


/*  Alternative 
type 

inletValue 

value 

*/ 

} 


BC 

inletOutlet ; 
uniform  (0  0  0 ) ; 
$internalField; 


inlet 


} 


type 

value 


f ixedValue ; 

$ internalField; 


// 


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 
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B.2.8  0/T 


/* - *_  C++  -* - *\ 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - */ 


FoamFile 

{ 

version  2.0; 

format  ascii; 

class  volScalarField; 

location  "0"; 

object  T; 

} 

//*************************************// 

dimensions  [0001000]; 

internalField  uniform  300; 

boundaryField 

{ 

wall-tunnel 


{ 


type 

1 

zeroGradient 

; 

wall -body 
; 

\ 

type 

zeroGradient 

outlet 

{ 


type 

inletOutletTotalTemperature 

U 

U; 

phi 

phi  ; 

psi 

psi  ; 

gamma 

l .  4  ; 

TO 

uniform  300; 

/*  Alternative 

BC 

type 

inletOutlet ; 

inletValue 

$internalField; 

value 

$ internalField; 

*/ 

} 

inlet 

{ 


type 

totalTemperature 

U 

U; 

phi 

phi  ; 

psi 

psi  ; 

gamma 

l .  4  ; 

TO 

uniform  300; 

/*  Alternative 

BC 

type 

f ixedValue ; 

value 

$ internalField; 

*/ 

j  j  *************************************************************************  j  j 
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B.2.9  0/k 


/* - *_  C++  -* - *\ 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

2.0.x 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - */ 


FoamFile 

{ 

version  2.0; 

format  ascii; 

class  volScalarField; 

location  "0"; 

object  k; 

} 

//*************************************// 
dimensions  [02-20000]; 

internalField  uniform  0.00375; 


boundaryField 

{ 

wall-tunnel 

{ 

type 

value 

} 

wall -body 

{ 

type 

value 

} 

outlet 

{ 

type 

inletValue 

value 

} 

inlet 

{ 

type 

intensity 

value 


compressible: : kqRWallFunction; 
uniform  0.00375; 


compressible: : kqRWallFunction; 
uniform  0.00375; 


inletOutlet ; 
uniform  0.00375; 
uniform  0.00375; 


turbulentIntensityKineticEnergyInlet ; 
0.01; 

uniform  12;  //based  on  avgU  of  10  m/s 


// 


// 
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B.2.10  0/ epsilon 


UNCLASSIFIED 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

2.0.x 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
location 
obj  ect 


2.0; 
ascii ; 

volScalarField; 
"  0  "  ; 

epsilon; 


} 

//*************************************// 
dimensions  [02-30000]; 

internalField  uniform  0.0005; 


boundaryField 

{ 


wall-tunnel 


type 

Cmu 

kappa 

E 

value 

} 

wall -body 

{ 

type 

Cmu 

kappa 

E 

value 


outlet 


type 

inletValue 

value 


inlet 


type 

mixingLength 

value 


} 

// 


compressible : : epsilonWallFunction; 
0.09; 

0.41; 

9.8; 

uniform  0.0005; 


compressible : : epsilonWallFunction; 
0.09; 

0.41; 

9.8; 

uniform  0.0005; 


inletOutlet ; 
uniform  0.0005; 
uniform  0.0005; 


compressible : : turbulentMixingLengthDissipationRatelnlet 
0.21;  //  0.07  X  Tunnel  Dia 

uniform  32;  //  based  on  k  of  12 


// 
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B.2.11  0/mut 


/* - *_  C++  -* - *\ 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

2.0.x 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - */ 


FoamFile 

{ 

version  2.0; 

format  ascii; 

class  volScalarField; 

location  "0"; 

object  mut; 

} 

//*************************************// 

dimensions  [1  -1  -1  0  0  0  0]  ; 

internalField  uniform  0; 

boundaryField 

{ 

wall-tunnel 

{ 

type 
Cmu 
kappa 
E 

value 

} 

wall -body 

{ 

type 
Cmu 
kappa 
E 

value 

} 

outlet 

{ 

type 
value 

} 

inlet 

{ 

type 
value 


j j  *************************************************************************  j j 


mutkWallFunction; 

0.09; 

0.41; 

9.8; 

uniform  0; 


mutkWallFunction; 

0.09; 

0.41; 

9.8; 

uniform  0; 


calculated; 
uniform  0; 


calculated; 
uniform  0; 
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UNCLASSIFIED 


B.2.12  0/ alpha! 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

2.0.x 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
location 
obj  ect 


2.0; 
ascii ; 

volScalarField; 
"  0  "  ; 
alphat ; 


} 

//*************************************// 
dimensions 


internalField 


[1  -1  -1  0  0  0  0], 
uniform  0; 


boundaryField 

{ 

wall-tunnel 

{ 

type 

Prt 

value 

} 

wall -body 

{ 

type 

Prt 

value 

} 

outlet 

{ 

type 

value 

} 

inlet 

{ 

type 

value 


alphatWallFunction; 

0.85; 

uniform  0; 


alphatWallFunction; 

0.85; 

uniform  0; 


calculated; 
uniform  0; 


calculated; 
uniform  0; 


// 


// 
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B.2.13  system/ controlDict 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
obj  ect 


2.0; 
ascii ; 
dictionary; 
controlDict ; 


} 

//*************************************// 

libs  ( " librotorDiskSource . so" ) ; 

application  rhoSimpleSourceFoam; 

startFrom  startTime; 

startTime  0; 

stopAt  endTime;  //writeNow; 

endTime  6000; 


deltaT 

writeControl 

writeinterval 

purgeWrite 

writeFormat 


1; 

timeStep ; 
1000; 

5; 

ascii ; 


writePrecision  12; 
writeCompression  uncompressed; 
timeFormat  general; 

timePrecision  6; 
runTimeModif iable  yes; 

II  *************************************************************************  II 


UNCLASSIFIED 


181 


UNCLASSIFIED 


DSTO-TR-2931 


B.2.14  system/  fvSchemes 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
obj  ect 


} 

// 


2.0; 
ascii ; 
dictionary; 
fvSchemes ; 


★  ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 


ddtSchemes 


default 


steadyState ; 


gradSchemes 

{ 

default 
grad (p) 
grad (U) 

limitedGrad (h) 


leastSquares ;  //Gauss  linear;  //Gauss  pointLinear; 
Gauss  linear; 

faceLimited  Gauss  linear  1; 
cellLimited  Gauss  linear  1; 


divSchemes 


default 
div (phi , U) 
//div(phi,U) 

div (phi , h) 
//div(phi,h) 

div (phi , k) 

div (phi , epsilon) 

div (phi , k) 

div (phi , epsilon) 


none  ; 

Gauss  upwind  grad(U) ; 

Gauss  linearUpwindV  grad{U); 

Gauss  upwind; 

Gauss  linearUpwind  limitedGrad (h) 


//1st  order  upwind 

//2nd  order  blended  upwind 


//2nd  order  blended  upwind 


Gauss  upwind; 

Gauss  upwind; 

Gauss  limitedLinear  0.5;  //  TVD  2nd  Order  Scheme 
Gauss  limitedLinear  0.5; 


} 


div (phi, K)  Gauss  upwind; 

div(U,p)  Gauss  linear; 

div ( (nuEf f *dev (T (grad (U) ) ) ) )  Gauss  linear; 

div ( (muEff*dev2 (T (grad (U) ))) )  Gauss  linear; 


laplacianSchemes 

{ 


} 


default 


interpolationSchemes 

{ 


default 


Gauss  linear  limited  0.333; 


linear; 


snGradSchemes 


default 


f luxRequired 

{ 


default 

p; 


limited  0 . 333 ; 


// 


ic'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 


1 1 
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B.2.15  system/fvSolution 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

dev 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . org 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
obj  ect 

} 

// 


2.0; 
ascii ; 
dictionary; 
fvSolution; 

★  ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 


solvers 

{ 

p 
{ 


solver 

tolerance 

relTol 

smoother 

nPreSweeps 

nPostSweeps 


GANG; 

le-7; 

0.1; 

GaussSeidel ; 
0  ; 

2; 


cacheAgglomeration  on; 
agglomerator  f aceAreaPair ; 

nCellsInCoarsestLevel  10; 


mergeLevels 


1; 


solver 

smoother 

tolerance 

relTol 

nSweeps 


smoothSolver ; 
GaussSeidel ; 
le-8  ; 

0.1; 

1; 


solver 

smoother 

tolerance 

relTol 

nSweeps 


smoothSolver; 
GaussSeidel ; 
le-8  ; 

0.1; 

1; 


epsilon 

{ 

solver 

smoother 

tolerance 

relTol 

nSweeps 

} 


{ 

solver 

smoother 

tolerance 

relTol 

nSweeps 


smoothSolver; 
GaussSeidel ; 
le-8  ; 

0.1; 

1; 


smoothSolver; 
GaussSeidel ; 
le-8  ; 

0.1; 

1; 


} 

SIMPLE 

{ 

nNonOrthogonalCorrectors  0; 

//  pRefCell  0; 

//  pRefValue  0; 
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0]  1; 

0 ]  1.4; 


} 

relaxationFactors 

{ 


rho 

1.0 

P 

0.2 

U 

0 . 3 

k 

0.3 

epsilon 

0.3 

h 

0 . 3 

} 

cache 

{ 

grad (U) ; 

} 


rhoMin  rhoMin  [1  -3  0  0 
rhoMax  rhoMax  [1  -3  0  0 

residualControl 

{ 

p  le-8 

U  le-9 

" (k I  epsilon) "  le-9 


// 


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 


// 
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B.2.16  system/  decomposeParDict 


C+  + 


w 

/ 

F 

ield 

OpenFOAM : 

The  Open  Source  CFD  Toolbox 

w 

/ 

0 

peration 

Version : 

1.7.0 

w 

/ 

A 

nd 

Web : 

WWW . OpenFOAM . com 

w/ 

M 

anipulation 

\* - 

FoamFile 

{ 

version 
format 
class 
obj  ect 


2.0; 
ascii ; 
dictionary; 
decomposeParDict ; 


} 

//*************************************// 
numberOf Subdomains  256; 


/ /method 
//method 
//method 

method 

simpleCoef f s 

{ 

n 

delta 


simple ; 
metis ; 
parMetis; 


scotch; 


(28  1  1)  ; 
0.001; 


hierarchicalCoef f s 


{ 


n 

delta 

order 


(4  2  1)  ; 
0.0001; 
xyz  ; 


manualCoef f s 


dataFile 


" cellDecomposition" ; 


metisCoef f s 


{ 


processorWeights  (11111111); 

distributed  no; 
roots  ( ) ; 


// 


// 
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B.2.17  monitorResiduals 


#  to  run  this  script  issue  the  commands: 

#  $  gnuplot  monitorResiduals 

set  logscale  y 
set  grid 

plot  "<  cat  script.log  |  grep  Ux  |  cut  -d'  '  -f9  |  tr  -d  t  "Ux"  with  lines,  "<  cat 

script.log  |  grep  Uy  |  cut  -d'  '  -f9  |  tr  -d  t  "Uy"  with  lines,  "<  cat  script.log  | 

grep  'for  omega, ' |  cut  -d'  '  -f9  |  tr  -d  t  "omega"  with  lines,  "<  cat  script.log  |  grep 

Uz,  I  cut  -d'  '  -f9  I  tr  -d  t  "Uz"  with  lines,  "<  cat  script.log  |  grep  'for  h, '  |  cut 

-d'  '  -f9  I  tr  -d  t  "energy"  with  lines,  "<  cat  script.log  |  grep  local  |  cut  -d'  '  -f9 

I  tr  -d  ' , ' "  t  " local_continuity"  with  lines,  "<  cat  script.log  |  grep  'for  p, '  |  cut  -d'  ' 

-f9  I  tr  -d  ' , ' "  t  "p"  with  lines 

pause  1  #  update  interval  (s) 

reread  #live  plotting  mode 

####  Uncomment  all  four  lines  below  to  save  the  plot  to  a  png  file  #### 

#set  terminal  png 
#set  size  1 , 1 

#set  output  " residuals . png" 

#replot 


#  File  name:  save. pit  -  save  a  Gnuplot  plot  as  a  PostScript  file 

#  to  save  the  current  plot  as  a  postscript  file  issue  the  commands: 

#  gnuplot>  load  ' saveplot ' 

#  gnuplot>  !mv  my-plot.ps  another-file.ps 

#  set  size  1.0,  0.6 

#  set  terminal  postscript  portrait  enhanced  mono  dashed  Iw  1  "Helvetica"  14 

#  set  output  "my-plot.ps" 

#  replot 
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B.2.18  runCaseOnSeadragonCluster 

# !  /bin/bash 

# 

###  PBS  ### 

#PBS  -N  GTITrimmed 

#PBS  -S  /bin/bash  -j  oe  -k  o  -r  n 

#PBS  -1  walltime  =  100 : 00  :  00 

#PBS  -1  select=16 : ncpus=16 : mpiprocs=16 

###  PBS  -1  select=32 : ncpus=16 : mpiprocs=16 
###  PBS  -1  select=28 :ncpus=16 :mpiprocs=16 

###  qsub  -1  select=8 : ncpus=16 : mpiprocs=16  ./Allrun 

### 

###  select=number_of_nodes  (1  to  32  nodes  in  cluster) 

###  ncpus=number  of  cores  per  node  (for  dual  AMD  6220  processor  nodes,  ncpus=16) 

###  mpiprocs=number  of  mpi  processes  per  node  (mpiprocs=16 ) 

### 

source  /datal/OpenFOAM/OpenFOAM-SGIRHEL62 -2 . 1 .  X_X8664_07JUTSIE12_REPO/setup  .  sh  DP  SGIMPI 
export  NCORES='cat  $PBS_NODEFILE  |  wc  -1" 

####################### 

cd  $PBS_0_W0RKDIR  #  NOTE  THAT  THIS  SCRIPT  MUST  BE  SUBMITTED  FROM  THE  WORK  DIRECTORY 

####################### 

rm  -rf  processor*  log  logs  script.log 

.  $WM_PROJECT_DIR/bin/ tool s/RunFunct ions 

unset  FOAM_SIGFPE 
echo  '  '  >  script.log 

echo  'Starting  the  Run'  >>  script.log 

echo  '=============================='  >>  script.log 

echo  "PBS:  Allocated  $NCORES  core(s)  on  node(s)  ""cat  $PBS_NODEFILE  |  sort  -u"  >>  script.log 

echo  "PBS:  Submitted  to  $PBS_QUEUE@$PBS_0_H0ST"  >>  script.log 

echo  "PBS:  Working  directory  is  $PBS_0_W0RKDIR"  >>  script.log 

echo  "PBS:  Job  identifier  is  $PBS_JOBID"  >>  script.log 

echo  "PBS:  Job  name  is  $PBS_JOBNAME"  >>  script.log 

echo  '=============================='  >>  script.log 

echo  '  ' 

#  System  variables 
HOST="uname  -n" 

OSTYPE="uname  -s" 

echo  'running  on  ' $HOST  $OSTYPE  '  using  mpi  routine  ' $FOAM_MPI  >>  script.log 
echo  ' '  >>  script.log 

CURDIR="pwd" 

runApplication  f oamlnstallationTest 

cat  log . f oamlnstallationTest  >>  script.log 

runApplication  checkMesh 

cat  log . checkMesh  >>  script.log 

#  Tell  PBS  of  available  nodes  on  the  cluster 
export  MPI_DSM_CPULIST= " 0 - 15 : allhosts " 

###  Add  job  sequence  here  ### 

decomposePar  -force  -cellDist  >  log . decomposePar  2>&:1 
cat  log . decomposePar  >>  script.log 

foamJob  -parallel  -screen  rhoSimpleSourceFoam  >>  script.log  2>&:1 
foamLog  log 

reconstructPar  >  log .  reconstructPar  2>&:1 
cat  log . reconstructPar  >>  script.log 

rm  -rf  processor* 
echo  ' ' 

echo  =========================================== 

echo  RUN  IS  FINISHED 

echo  =========================================== 

echo  ' ' 
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